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There  Is  a continuing  need  for  good  planning  whereby  all  resources 
available  to  local  Civil  Defense  directors  will  be  used  effectively  in 
countering  the  devastating  effects  of  a nuclear  attack.  Analytical  studies 
have  not  yielded  convincing  proof  that  this  need  will  be  satisfied  by  manual 
methods.  An  alternative  or  complementary  approach  to  manual  methods  is  a 
computer  simulation  for  The  Test  and  Evaluation  of  Local  Operating  Systems 
(TELOS)  that  has  been  under  development  for  some  time  with  various  configu- 
ration changes  in  the  past  several  years. 

During  the  past  year,  RTI  has  continued  to  develop  a countermeasures 
model  called  LEMOS  as  a part  of  TELOS.  The  original  purpose  of  this  project 
was  to  develop  a means  by  which  in-house  DCPA  analyses  could  be  made  of 
emergency  operations,  including  communication  for  crisis  relocation  planning 
implementation. 

As  a result  of  a planning  meeting  with  DCPA  project  monitors,  the 
priority  of  effort  on  a communications  model  was  reduced  in  favor  of  greater 
emphasis  on  integration  under  an  executive  routine  for  functional  modules 
already  developed.  Moreover,  the  change  from  CDC  to  UNIYAC  computation 
equipment  at  the  Defense  Civil  Preparedness  Computation  Center  (DCPACC) 
required  a redesign  and  redevelopment  of  the  executive  control  procedures. 

As  a result,  RTI  redirected  its  efforts  toward  creating  a new  control 
main-line  program,  refining  the  file  management  system,  and  performing  test 
runs  on  the  LEMOS  system. 

The  executive  control  procedures  (GENEC)  developed  at  DCPACC  were  never 
applied  to  the  control  of  LEMOS  modules.  The  procedures  were  dependent  on 
the  CDC  operating  system  characteristics  at  DCPACC.  Since  DCPACC  was 
installing  a UNIVAC  1100/10  to  replace  the  CDC  equipment,  it  was  necessary 
to  plan  and  develop  an  executive  control  system  compatible  with  the  new 
UNIVAC  system.  However,  the  UNIVAC  system  was  not  installed  at  the  time 
this  need  became  apparent. 

The  main  accomplishments  during  the  contract  period  were  the  develop- 
ment of  a prototype  executive  control  for  LEMOS  (and  for  TELOS  as  well)  and 
improved  management  of  interconnecting  files.  The  previous  method  of 
executive  control  employed  a tape  oriented  system  closely  related  to  the 
CDC's  operating  system.  The  current  program  control  module  (DCPAMAIN) 
eRq>loys  a series  of  CALL  operations  in  an  overlay  fashion.  The  overlay 
structure  approach  in  DCPAMAIN  appears,  after  study,  to  be  compatible  with 
the  UNIVAC  1100/10  at  DCPACC.  Therefore,  all  COBOL  and  FORTRAN  programs  at 
RTI's  computation  facility  (TUCC),  should  be  converted  to  operate  on  the 
UNIVAC  1100/10  without  further  major  modification. 

The  relatively  large  number  of  files  used  by  the  LEMOS  system  requires 
special  attention  to  the  file  management  so  as  to  minimize  I/O's  and  their 
Impact  on  running  time  and  cost.  There  are  seventeen  potential  program 
runs,  and  there  are  forty-one  files  that  must  be  maintained  during  these 
runs.  During  the  contract  period,  RTI  attempted  to  minimize  the  total 
number  of  files  used  and  the  number  used  in  each  program  run. 

RTI  recommends  that  the  LEMOS  system  be  converted  from  the  IBM  370/165 
at  TUCC  to  the  UNIVAC  1100/10  at  DCPACC.  After  conversion,  the  following  I 

developmental  tasks  should  be  undertaken:  determine  detailed  scenario  input  ] 

and  output  requirements;  integrate  other  TELOS  models  (GENUA,  LOCATE,  AOS) 
and  LEMOS  under  the  same  executive  control;  enable  AOS  to  assess  special  CD 
resources  and  network  link  damage;  coordinate  processing  between  AOS  and 
LEMOS/Operations  Model  to  prevent  misestimation  of  injuries  and  deaths;  and 
develop  an  accounting  monitor  to  debug  the  TELOS  system  and  perform 
extensive  testing  to  evaluate  system  capabilities. 
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The  research  described  In  this  document  covers  the  Integration 
of  the  Local  Emergency  Operating  System  (LEMOS)  computer  programs 
Into  a consolidated  set  of  selectable  program  modules  under  control 
of  a resident  main  line  program.  OUrlng  the  past  year,  RTI  — 
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continued  to  develop  this  countermeasures  model  as  a part  of 
TELOS.  The  relatively  large  number  of  files  used  by  the  LEMOS 
system  requires  special  attention  to  file  management  so  as  to 
minimize  I/O's  and  their  Impact  on  running  time  and  cost.  RTI 
recommended  that  the  LEMOS  system  be  converted  to  operate  In  the 
UNIVAC  1100/10  operating  system  environment,  and  that  It  be  tested 
extensively  as  a part  of  TELOS  to  evaluate  local  CD  system 
capabilities. 
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The  research  reported  herein  covers  the  Integration  of  the  Local 
Emergency  Operating  System  (LEMOS)  computer  programs  into  a consolidated  set 
of  selectable  program  modules  under  control  of  a resident  main  line  program 
module.  This  work  is  sponsored  by  the  Defense  Civil  Preparedness  Agency 
(DCPA)  under  Contract  No.  DCPA01-76-C-0333  and  Work  Unit  41261. 

The  authors  express  their  indebtedness  to  Mr.  Donald  Hudson  and 
Mr.  James  Jacobs  of  DCPA  for  their  guidance  during  the  study.  The  authors 
also  express  their  appreciation  to  Mr.  Edward  L.  Hill  and  to  others  in  the 
Research  Triangle  Institute  who  supported  this  research. 


ABSTRACT 


A computer  simulation  for  The  Test  and  Evaluation  of  Local  Operating 
Systems  (TELOS)  has  been  under  development  for  some  time.  During  the  past 
year,  RTI  has  continued  to  develop  a countermeasures  model  called  LEMOS  as  a 
part  of  TELOS.  The  main  accomplishments  during  the  contract  period  were  the 
development  of  a prototype  executive  control  module  for  LEMOS  and  Improved 
management  of  Interconnecting  files.  The  executive  control  module  employs  a 
series  of  CALL  operations  In  an  overlay  fashion.  Special  attention  was 
given  to  file  management  so  as  to  minimize  I/O's,  running  time,  and  cost. 

RTI  made  several  recommendations  for  continued  effort  on  LEMOS  and  TELOS. 
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1.  BACKGROUND 


A.  Introduction 

There  is  a continuing  need  for  good  planning  whereby  all  resources 
available  to  local  civil  defense  directs.  ; ..ill  be  used  effectively  in 
countering  the  devastating  effects  of  a nuclear  attack.  Because  of  the 
enormous  complexity  of  local  civ!’  defense  operations,  analytical  studies 
have  not  yielded  convincing  proof  that  this  need  will  be  satisfied  by 
manual  methods,  even  though  efforts  at  local  command  and  control  exercises 
are  commendable.  An  alternative  or  complementary  approach  to  manual  exer- 
cises is  a computer  simulation.  This  approach  is  embodied  in  a semi- 
automatic analytical  system  called  TELOS.  TELOS  stands  for  The  Test  and 
Evaluation  of  Local  Operating  Systems  and  has  been  under  development  for 
some  time  with  various  configuration  changes  in  the  past  several  years. 
Figure  1 is  a schematic  of  the  overall  system  design.  Scenario  definition 
and  performance  evaluation  are  intended  in  large  part  to  be  accomplished  by 
analysts  through  manual  procedures.  Zonal  data  preparation  should  not  be 
automated  until  all  data  requirements  have  been  adequately  defined. 
Therefore,  data  preparation  is  now  performed  manually  by  developing  a Master 
Status  File  (an  enumeration  of  resources  at  the  time  a scenario  begins). 

The  executive  control,  attack,  damage  assessment,  and  countermeasures  models 
all  exist  in  various  stages  of  development.  Although  none  of  these  models 
are  considered  complete,  they  are  approaching  a point  at  which  they  will 
enable  in-house  DCPA  analyses.  In  fact,  one  version  of  AOS  has  been  used  to 
assess  damage  in  a stu4y  of  several  cities  [Ref.  1].  However,  the  main 
TELOS  system  including  countermeasures  remains  to  be  integrated. 

During  the  past  year,  RTI  has  continued  to  develop  LEMOS  as  a part  of 
TELOS.  The  original  purpose  of  this  project  was  to  develop  a means  by  v4)ich 
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Figure  1.  Overall  TELOS  System 
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In-house  OCPA  analysis  can  be  made  of  emergency  operations.  Including 
communications  for  Crisis  Relocation  Planning  (CRP)  Implementation. 
Consequently,  the  work  plan  was  oriented  toward  the  development  of  a communi- 
cations subsystem  module  capable  of  assessing  communications  support  for  both 
crisis  relocation  and  trans-attack  operations. 

Under  the  concept  of  CRP,  residents  of  areas  having  a high  risk  of 
receiving  direct  weapons  effects  from  a nuclear  attack  are  relocated  to  areas 
with  a lower  risk  of  receiving  these  effects.  This  type  of  planning  specifies 
that  the  population  relocation  would  be  Implemented  In  the  face  of  Inter- 
national tensions  which  have  Implications  of  ending  in  war. 

Major  considerations  in  the  development  of  such  plans  are  the  risk 
levels  In  each  unit  area,  the  geographic  distribution  or  development  of 
resource  systems,  and  the  command  and  control  system(s)  Including  communica- 
tion networks.  An  analytic  system  is  needed  to  analyze  the  planning 
parameters,  especial^  requirements  for  communications  for  direction  and 
control  in  the  event  a CRP  is  activated.  Most  of  the  host  or  reception  areas 
to  ti4iich  the  population  at  risk  would  be  relocated  are  widely  dispersed  and 
contain  a minimum  of  resources.  These  factors,  along  with  the  large  variety 
and  interactions  between  resource  systems,  argue  for  an  analytic  system 
capable  of  handling  large  quantities  of  data.  The  Area  Damage  Summary  (AOS) 
System  developed  by  KPA  and  the  Local  Emergency  Operation  System  (LEMOS) 
developed  by  RTI  are  expected  to  provide  a basis  for  the  TELOS  analytic 
system.  To  utilize  AOS  and  LEMOS  effectively,  compatible  definitions  are 
required  by  which  state  and  local  plans  are  Interfaced  with  the  description 
of  target  and  relocation  areas  and  their  resources.  Implementation  of  these 
plans  by  decision  makers  Invokes  demands  for  resource  expenditures  and  means 
for  communicating  Instructions  and  receiving  status  reports.  The  problems  of 
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connand  and  control  In  CRP's  are  compounded  by  the  presence  of  attack  effects. 

As  a result  of  a planning  meeting  with  OCPA  project  monitors  {Messrs. 
Donald  Hudson  and  James  Jacobs),  the  effort  on  a communications  model  was 
reduced  In  priority  In  favor  of  greater  emphasis  on  Integration  under  an 
executive  routine  of  functional  modules  already  developed.  Moreover,  the 
change  from  COC  to  UNIVAC  computation  equipment  at  the  Defense  Civil 
Preparedness  Computation  Center  (DCPACC)  required  a redesign  and  redevelopment 
of  the  executive  control  procedures.  As  a result,  RTI  redirected  Its  efforts 
toward  creating  a new  control  main-line  program,  refining  the  file  management 
system,  and  performing  test  runs  on  the  LEMOS  system. 

B.  TELOS  Procedures 

The  system  programs  called  TELOS  was  (^signed  as  a research  tool  to 
test  and  evaluate  local  operating  systems  concepts.  Subsequently,  three 
additional  uses  have  been  described:  (1)  as  a countermeasure  assessment  aid 
for  natural  civil  defense  evaluations;  (2)  as  a planning  aid  for  local  CD 
planners;  and  (3)  as  a training  aid  to  simulate  attack  scenarios  for  local 
CD  directors.  Each  of  these  additional  roles  would  require  Inputs  and 
outputs  different  from  those  described  In  current  executive  control 
procedures.  In  general,  the  overall  TELDS  description  In  Figure  1 Is 
directed  toward  the  research  role.  Detailed  studies  of  changes  to  that 
system  for  non-research  roles  have  not  been  undertaken,  even  though  some 
consideration  has  been  given  to  them  In  preparing  the  program  module 
developed  to  date.  More  effort  has  gone  Into  the  static  role  Involving  the 
attack  and  damage  assessment  models  than  the  dynamic  role  using  LEMOS.  The 
primary  change  In  the  system  description  presented  In  earlier  reports  Is  the 
replacement  of  GENEC  with  DCPAMAIN. 

Briefly,  the  TELOS  system  functions  under  the  control  of  a basic 
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scenario,  through  the  use  of  an  executive  routine  called  DCPAMAIN  (see 
section  II).  The  local  area  (or  zone)  is  described  by  configuring  a local 
area  from  statistical  data  about  local  areas  contained  in  a data  base.  The 
resources  in  the  simulated  area  derived  from  the  data  base  can  be  varied 
depending  upon  the  scenario  and  special  local  considerations.  Thus,  a 
target  model  (GENUA)  enables  the  interactive  preparation  of  the  Master 
Status  File  (fiSF).  Included  in  TELOS  is  an  attack  model  v^ich  generates 
overpressure  as  well  as  thermal,  prompt,  and  fallout  radiation  levels  at 
various  points  over  the  entire  local  area.  The  Area  Damage  Sumnary  (AOS) 
System  relates  the  resources  to  the  environmental  effects  generated  by  the 
attack  model  and  describes  the  resulting  damage  in  the  MSF.  The  Local 
Emergency  Operating  System  (LEMOS)  responds  with  countermeasures  to  problems 
derived  from  an  examination  of  both  actual  and  potential  resource  damage, 
thus  altering  the  state  of  local  resources. 

The  TELOS  system  iterates  between  the  countermeasures  (LEMOS)  and  damage 
assessment  (ADS)  models,  continuing  through  a number  of  time  periods  under 
control  of  the  basic  scenario  (via  DCPAMAIN).  Manual  evaluation  of  system 
outputs  is  contemplated  at  this  time.  A mechanized  evaluation  model  may  be 
needed  to  analyze  the  large  amount  of  outputs  as  they  apply  to  a particular 
role  of  TELOS.  On  the  basis  of  this  evaluation,  controls  for  further 
iterations  are  determined  and  Implemented  in  TELOS  through  the  use  of 
DCPAMAIN,  and  a new  cycle  begins.  Throughout  the  course  of  the  simulation, 
reports  are  generated  to  measure  the  status  of  the  system  under  test  as  a 
basis  for  the  evaluation  of  local  emergency  operations. 
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C.  LEMOS  Model 


Figure  2 shows  the  major  elements  that  make  up  the  LEMOS  model.  The 
following  paragraphs  describe  briefly  each  of  the  major  elements  i«*)1ch 
constitute  LEMOS. 

Organization  of  civil  defense  countermeasures  to  meet  undesirable 
situations  begins  with  the  problem  definition  model.  Each  resource  in  the 
Inventory  Status  File  is  examined  with  respect  to  its  damage  state  and 
environment.  A set  of  problems  is  identified  which  requires  that  a counter- 
measure be  conducted  to  solve  or  improve  the  prevailing  situation.  A 
counterpart  of  these  problems  is  the  availability  of  resources  to  implement 
proposed  countermeasures.  Shortage  or  damage  to  these  resources,  particu- 
larly injury  to  personnel,  adds  control  and  readiness  problems  to  those 
already  recognized  as  requiring  remedial  action.  Availability  of  CO 
resources  is  defined  by  a resource  matrix  organized  by  land  use  or  service 
function  and  resource  type  associated  with  each  function.  The  output  of  the 
problem  definition  model  is  a Resource  File  and  a Problem  File  containing 
four  general  classes  of  problems:  control,  readiness,  damage  control,  and 
relief  and  rehabilitation.  Records  of  two  or  more  classes  exist  for  each 
land-use  entry  within  a unit  area  since  control  and  readiness  problems  are 
always  present.  The  objective  of  LEMOS  is  to  resolve  all  of  these  problems. 

The  first  function  of  the  requirements  model  is  to  update  service 
records  and  identify  increased  readiness  and  control  problems.  After 
updating,  sufficient  information  is  available  to  prepare  alternative 
assignments.  The  requirements  model  has  been  written  to  include  a table- 
lookup  capability  to  generate  resource  requirements.  The  Service  File  is 
updated  with  respect  to  the  status  of  teams  by  examining  the  Resource  and  the 
"new"  Problem  Files.  For  example,  if  a change  due  to  injury,  entrapment. 
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or  other  mishap  reduces  the  number  of  eligible  civil  defense  people, 
adjustments  In  the  number  of  teams  and,  perhaps,  their  functions  and  state 
distributions  are  necessary.  Updating  Is  also  necessary  If  the  magnitude  of 
a problem  has  decreased,  so  adjustments  Mould  have  to  be  made  In  existing 
assignments  and  then  In  team  states.  An  example  of  the  need  for  updating  In 
service  status  Is  the  death  of  people  scheduled  for  rescue  while  teams  are 
enroute  to  the  site.  Therefore,  the  status  of  teams  may  change  from  active 
to  Inactive,  pending  reassignment.  Changes  In  equipment  or  supply  are  made 
by  updating  the  service  status  file  and  by  noting  any  new  Increased  readiness 
or  control  problems.  After  updating,  appropriate  records  are  selected  for 
processing  through  each  functional  model.  The  output  of  the  requirements 
model  Is  an  Operations  File  that  records  the  alternative  solutions  to  all 
problems  defined  by  the  Problem  File  and  an  Assignment  File  that  records  each 
function  In  each  operation. 

The  transportion  subsystem  contains  a series  of  programs  shown  In 
Figure  3 that  determines  the  minimum  transportation  times  between  unit  areas. 
Freeways  and  major  arteries  are  the  basis  of  the  current  development  of  the 
transportation  network.  Residential  and  feeder  streets  are  not  Included  as 
they  unnecessarily  expand  the  network  to  unmanageable  proportions.  Inter- 
sections of  highways  and  arteries  define  nodes  In  the  network.  Additional 
nodes  could  be  added.  If  desired,  at  non-intersection  points.  The  segment 
between  two  nodes  Is  a link  In  the  network.  Nodes  are  Identified  by  unique 
numbers.  Connectivity  of  Unit  Areas  Is  determined  by  the  occurrence  of  equal 
node  numbers.  Links  are  Identified  by  numbers  and  names.  Link  Identifica- 
tion Is  not  Involved  computationally  In  the  current  computerized  transporta- 
tion model;  It  Is  used  only  to  aid  in  creating  the  Links  File  data  base. 

The  transportation  network  Is  described  by  the  Links  File.  The  data  In  this 
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file  Is  used  to  create  the  mar.rlx  of  distances  between  directly  linked  nodes 
In  a unit  area  network. 

The  computerized  Transportation  Subsystem  computes  the  path  of  minimum 
travel  time  between  all  unit  areas  and  creates  the  TVLREF  file.  The  problems 
are  defined  In  unit  areas  v^lch  are  separated  In  terms  of  distances,  and  the 
conversion  from  distance  to  travel  time  Is  made  by  assuming  a speed  of 
45  miles  per  hour.  The  Input  data  to  the  computer  model  consist  of  two  flies 
(the  Links  File,  which  describes  each  unit  area  network  In  Its  Initial  state, 
and  a Control  File,  which  Identifies  the  numbers  of  the  unit  area  networks 
selected  for  processing).  The  computer  program  has  been  written  to 
accommodate  unit  area  networks  containing  a maximum  of  75  nodes  each  and  a 
zonal  network  containing  a maximum  of  400  unit  areas.  It  has  been  tested  on 
a network  of  8 unit  areas  containing  from  6 to  26  nodes. 

There  are  two  major  steps  In  the  model.  The  first  Is  a "one-for-all" 
step  that  computes  shortest  paths  between  all  nodes  In  a unit  area  network 
and  the  distances  between  directly  linked  unit  area  networks.  This  step  uses 
the  Link  and  Control  Files  previously  mentioned.  The  second  step  uses  the 
Basic  Operating  Situation  (BOS)  of  each  unit  area  from  the  Resource  File  to 
alter  these  distances  and,  then,  to  compute  the  shortest  paths  between  all 
unit  areas.  The  second  step  can  be  repeated  as  often  as  necessary  as  BOS 
changes  occur  over  time  In  a given  scenario.  Both  steps  use  Floyd's 
algorithm  to  compute  the  shortest  paths  between  all  nodes.  In  addition  to 
Floyd's  algorithm,  (which  solves  for  all  shortest  paths  from  all  nodes  In  a 
network  to  either  one  or  all  other  nodes),  another  efficient  method  Is 
Oljkstra's  algorithm,  which  solves  for  either  the  shortest  path  between  two 
specified  nodes  or  the  shortest  paths  from  a specified  origin  to  all  destina- 
tions. 
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The  output  from  this  subsystem  is  a Travel  Reference  (TVLREF)  File  that 
quantifies  the  travel  time  between  unit  areas  after  considering  the  damage 
and  operating  environments  affecting  the  transportation  system  in  the  zone  of 
operations. 

The  assignment  subsystem  depicted  in  Figure  4 uses  the  operations  and 
initial  Assignment  File  from  the  requirements  model  and  the  Travel  Reference 
File  from  the  transportation  subsystem.  The  number  of  teams  and  the  average 
time  each  team  requires  to  implement  each  operation  are  used,  subject  to 
constraint,  to  determine  assignments  for  all  teams  under  the  Jurisdiction  of 
a specified  control  point.  This  allocation  procedure  [Ref.  2],  an  adaptation 
of  an  efficient  algorithm  developed  by  RTI  [Ref.  3],  assigns  resources  to 
alternative  programs.  Demands  not  assigned  are  retained  for  subsequent 
allocation  of  unassigned  resources  in  later  periods.  Provision  has  been 
made  to  permit  externally  assigned  priorities  to  override  internally 
assigned  priorities.  After  all  assignment  decisions  have  been  made  and  new 
and  old  operations  records  have  been  combined,  the  evaluation  procedure 
enters  the  operational  phase  for  the  deployment  of  resources  and  the 
execution  of  mission  assignments. 

Planning  for  team  and  supply  distribution  over  the  network  of  lines  and 
links  is  accomplished  in  the  deployment  model.  A minimum  Route  (TVLREF)  File 
was  generated  in  the  transportation  subsystem  for  all  moves  between 
admissible  origins  and  destinations  within  a network.  Selected  minimum  paths 
consider  network  problems  (e.g.,  radiation  and  blocked  streets)  evident  in 
the  current  period.  This  Route  File  is  the  source  of  all  movement  time 
entries  in  trip  records.  Resource  availability  and  functional  capability  are 
the  two  main  criteria  for  geierating  movement  requests.  If  the  environment 
prevents  functional  performance  or  resources  are  not  available  in  a specific 
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Figure  4.  Assignment  Subsystem 
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area,  neighboring  areas  are  searched  to  establish  minimum  time  moves  that 
resolve  these  problems.  Searches  are  conducted  In  order  of  operational 
priority  and  two  trip  records  are  generated.  The  first  Is  used  to  subtract 
resources  at  the  origin,  and  the  second  Is  used  to  add  resources  at  the 
destination.  If  arrival  times  have  not  been  reached  at  the  end  of  the 
current  period,  the  resources  are  placed  In  an  "In-transit"  status.  The  Trip 
File  Is  the  primary  output  of  the  deployment  model. 

Normally,  deployment  Is  made  possible  at  the  beginning  of  the  operations 
phase  at  rates  specified  by  two  trip  records  generated  In  the  deployment 
model.  These  two  records  are  sorted  Into  origin  and  destination  locations  In 
a sorting  operation  between  the  deployment  and  operations  models.  Operations 
records  are  processed  In  the  operations  model  by  priority  In  the  presence  of 
assignment  records  organized  by  area,  operation  number,  and  land  use. 
Available  resources  are  expended  In  exchange  for  problem  resolution.  Changes 
In  resource  states  are  recorded  In  the  Benefit,  Problem,  and  Resource  Files. 
The  operations  model  has  not  been  completed  with  respect  to  processing  all 
functions.  The  completion  of  this  model  must  be  coordinated  closely  with 
respect  to  the  completion  of  the  ADS  special  resources  damage  assessment  for 
population  deaths  and  Injuries.  This  coordination  Is  deemed  essential  to  the 
proper  execution  of  TELOS  and  should  be  undertaken  In  the  next  contract 
period. 

The  Benefit  File  Is  used  In  the  report  generating  model  to  describe 
benefits,  readiness,  and  team  effectiveness.  The  changed  Resource  and 
Problem  Files  are  Input  to  the  final  step  In  the  countermeasures  model  before 
redefining  the  resource  status  and  recording  the  vulnerability  In  the 
Inventory  Status  File.  During  the  reporting  period,  a report  generator  uses 
two  files.  The  first  Is  a Performance  File  generated  In  the  operations 
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model.  It  contains  team  performance,  population  benefits,  and  readiness 
information.  The  second  file  contains  historical  operations  data  from 
previous  periods.  Data  from  these  two  files  are  processed  and  the  cost- 
benefit  measures  are  developed  and  displayed  In  two  reports,  the  Team  Effec- 
tiveness Report  {Figure  5)  and  the  Benefit  Report  (Figure  6).  In  addition, 
the  program  has  the  capability  of  plotting  data  from  "the  two  reports  to  allow 
visual  scanning  for  significant  changes  over  time.  The  plotting  procedure 
can  plot  four  (4)  data  sets  for  each  time  period.  An  example  of  this  form  of 
output  may  be  seen  In  Figure  7.  Four  different  sets  of  plots  may  be  produced 
displaying  the  values  of  16  data  elements. 

As  the  countermeasures  model  Is  Integrated  with  the  evaluation  model, 
additional  data  requirements  are  likely  to  evolve.  If  so,  then  this  report 
generating  procedure  probably  will  be  altered  to  meet  these  new  needs. 

The  final  module  In  the  LEMOS  series  of  programs  Is  called  the  Inventory 
protection  model.  Where  the  people  are  located  (e.g..  In  single  family 
residential  units  or  NFSS  shelters)  determines  the  protection  level  or, 
conversely,  the  vulnerability  level  of  people.  People  are  loaded  Into 
shelters,  and  Inventory  records  are  prepared  according  to  the  control  policy 
and  posture  constraints  prevailing  at  each  location.  This  model  uses  the 
Problem  and  Resource  Files  from  the  operations  model  to  update  the  status  of 
resources  In  the  Master  Status  File  (MSF)  from  the  damage  assessment  (ADS) 
model.  Three  files  (Problem,  Resource,  and  MSF)  are  manipulated  to  update 
the  MSF  file.  The  MSF  file  Is  Identified  here  to  emphasize  the  significant 
aspects  of  this  Interface.  If  area  data  remains  unchanged,  the  file  Is 
transferred  directly  to  the  updated  file;  structural  data  and  area  situations 
are  generated  from  the  previous  MSF  and  Problem  Files;  personnel  records  are 
generated  largely  from  the  Problem  File;  resource  records  are  generated  from 
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Figure  6.  Area  Benefit  Report 


both  the  Resource  and  the  Master  Status  files;  and  shelter  space  records  are 
transferred  from  the  the  MSF.  The  final  function  of  this  model  Is  to  fill 
shelter  spaces  according  to  the  control  pokicy  and  to  record  the  protection 
factors  for  the  occupants. 

At  this  point  In  the  evaulatlon,  one  pass  has  been  completed  through  the 
countermeasures  model  by  taking  the  Master  Status  File  from  the  damage 
assessment  (ADS)  model  and  returning  an  equivalent  file.  The  MSF  was  modi- 
fied to  reflect  civil  defense  countermeasures  during  the  specified  time 
Intprval.  In  the  course  of  planning  and  executing  the  specified  counter- 
measures, a number  of  files  were  created,  modified,  and  retained  for  the  next 
process  period.  Processing  continues  until  the  number  of  time  periods 
required  by  the  system  control  model  terminates  the  simulation.  A large 
number  of  printout  options  provided  within  the  LEMOS  and  ADS  yields  a running 
description  of  system  performance.  Output  data  may  be  processed  at  the  con- 
clusion of  each  pass  or  at  the  time  of  termination. 

Analysis  of  reports  produced  by  successive  periods  of  performance  Is  the 
basis  for  evaluations  of  the  effectiveness  of  local  operations  regardless  of 
which  of  the  following  roles  TELOS  Is  playing: 

(1)  research, 

(2)  national  assessment, 

(3)  planning,  or 

(4)  training. 

As  stated  earlier,  the  primary  development  during  the  past  year  Is  the 
creation  of  a new  executive  control  mainline  program  (DCPAMAIM)  to  replace 
GENEC,  which  was  described  In  last  year's  report  [Ref.  4].  This  development 
Is  described  In  Section  II  of  this  report  and  Introduces  the  basis  for  devel- 
ment  of  DCPAMAIN  and  the  file  management  changes  presented  In  Section  III. 

17 


II.  LEMOS  SYSTEM  CONTROL 
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A.  Introduction 


The  GENEC  executive  control  procedures  developed  at  DCPACC  were  never 
applied  to  the  control  of  LEMOS  modules.  The  procedures  were  dependent  on 
the  CDC  operating  system  characteristics  at  DCPACC.  Since  DCPACC  was 
Installing  a UNIVAC  1100/10  to  replace  the  CDC  equipment.  It  was  necessary 
to  plan  and  develop  an  executive  control  system  compatible  with  the  new 
UNIVAC  system.  However,  the  UNIVAC  system  was  not  Installed  at  the  time 
this  need  became  apparent.  Therefore,  RTI  designed  an  executive  control 
system  on  IBM  equipment  based  on  overlays  and  calls  that  were  known  to  be 
relatively  compatible  with  the  UNIVAC  system.  The  following  sections  will 
describe  the  overlay  procedures  In  general,  and  the  specific  procedures  on 
the  IBM  and  UNIVAC  equipment. 

B.  Program  Overlaying  and  Calls 

The  sequence  of  program  module  execution  requires  a method  to  specify 
module  selection.  The  particular  method  employed  depends  upon  features 
available  on  the  computer  designated  by  the  user.  The  previous  method  of 
executive  control  employed  a tape  oriented  system  closely  related  to  the 
CDC's  operating  system.  The  current  program  module  control  system  employs 
a series  of  CALL  operations  In  an  overlay  fashion. 

If  a set  of  programs  requires  more  memory  area  than  Is  available,  as  Is 
the  case  with  TELOS  and  LEMOS,  then  a method  must  be  found  to  reduce  memory 
area.  An  "overlay"  procedure  permits  a program  to  run  on  a computer  vaien 
this  Is  the  situation.  "When  a section  of  computer  code  Is  loaded  Into  a 
central  memory  area  that  was  previously  allocated  to  another  section  of  the 
same  executing  program,  the  process  Is  called  "overlaying"  [Ref.  5].  An 
Initial  or  "main"  part  of  the  program  Is  loaded  Into  core  memory;  the 
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remalnuer  is  maintained  in  peripheral  storage  (usually  direct  access). 

During  program  operation,  instructions  are  executed  to  cause  part  (or  all) 
of  the  core  memory  to  be  overlayed  by  specified  program  sections  from 
off-line  storage.  In  a typical  system,  an  overlay  tree  can  be  specified  as 
shown  in  Figure  8.  A base  or  root  segment  is  defined  by  the  programmer  and 
remains  in  core  throughout  the  running  of  the  program.  One  of  the  first 
level  overlays  A,  B,  or  C may  occupy  the  area  Just  beyond  the  end  of  the 
root  segment.  Assuming  that  the  branch  A-E-M  is  operating,  then  E is  just 
beyond  A,  and  M is  just  beyond  E.  The  programmer  defines  the  beginning  and 
ending  of  each  segment  and  its  position  in  the  tree  structure.  The 
language  processing  system  will  organize  the  object  modules  into  a structure 
residing  in  peripheral  storage  from  which  the  necessary  overlays  are  loaded 
at  execution  time.  If  the  operating  system  has  "virtual  memory"  capabili- 
ties, then  overlaying  is  completely  automatic. 

The  "calls"  in  the  main  program  initiate  the  overlaying  process  and 
indeed  control  the  sequencing  of  overlays  as  needed  by  the  scenario. 
"Looping"  of  the  calling  sequence  enables  the  system  to  repeat  the  required 
number  of  times.  The  overlay  structure  for  LEMOS  is  simple  and  will  be 
described  in  the  next  section. 


C.  Executive  Control  Procedures 

Figure  9 contains  a copy  of  the  linkage  editor  output  from  the  IBM  run 
establishing  the  overlay  structure  of  the  LEMOS  system  procedure.  As  can  be 
seen  from  this  description,  a general  sorting  procedure  called  DCPASORT  has 
been  added  to  the  program  set  in  addition  to  the  resident  main  module 
(RESMAIN).  Programs  NGM3A  through  NGM3E  are  a set  of  programs  accomplishing 
the  transportation  or  minimum  route  determination  function.  The  report 


generator,  NGM8,  was  not  included  but  can  be  added  when  needed.  Otherwise, 
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programs  1 through  9 In  the  LEMOS  series  (as  described  in  Figure  2)  are 
Identified  as  NGMl  through  NGM9  in  the  overlay. 


The  current  listing  of  the  executive  module  using  this  structure  is 
contained  in  Appendix  A.  The  resident  main  program  has  been  used  to  test 
the  procedure. 

The  overlay  system  was  demonstrated  by  making  several  runs  on  the  IBM 
370/165  computer  at  the  Triangle  Universities  Computation  Center  (TUCC). 
Figure  10  shows  the  control  statements  for  a run  of  the  Transportation 
Subsystem.  Other  runs  with  similar  control  statements  were  made  on  the 
LEMOS  set  of  programs.  The  control  data  cards  for  these  runs  is  illustrated 
in  Figure  11.  Each  card  calling  for  a program  execution  is  followed  by  a 
second  record  containing  parameters  used  to  control  that  program.  These 
tests  were  not  exhaustive,  nor  did  they  attempt  to  determine  resource 
accountability  between  inputs  and  outputs  for  each  program.  Further  testing 
should  include  an  accountability  report  between  each  program  to  aid  in  the 
tracking  of  resources  between  programs.  This  report  will  reduce  the  manual 
effort  devoted  to  this  time  consuming  task  required  to  verify  the  accuracy 
of  the  simulation  procedures.  However,  the  results  of  these  test  runs 
confirm  the  feasibility  of  this  approach.  Finalization  of  DCPAMAIN  should 
await  more  complete  testing  of  the  series  after  conversion  to  the  UNIVAC 
1100/10  at  DCPACC. 

At  present,  the  program  sequence  is  determined  by  a series  of  control 
cards  read  by  the  main  program.  Run  switches  on  the  date  cards  select  the 
program  modules  required  for  execution.  RTI  recommends  that  this  procedure 
be  modified  by  converting  this  record  set  into  a table  which  can  be 
interactively  changed  prior  to  system  runs.  Moreover,  these  interactive 
sessions  should  be  planned  as  a part  of  the  scenario  and  controlled  by 
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//FTJOFOOl  DO  Ut;l  rsolSKfOlSPsSHK, 

//  V(JLsSt»V  = K riilCU.US'JSif  st.nftlist 
//FTSIFOOI  00  UNlIsOibKjni.SPsSHP, 

//  VdLsSCWaWt  lUCO,0Srjs  rtST  .L  INfS 
//FT53F001  00  UN  I rs(H  SK , I)  I SPsSmR  , 

//  VOLSStWsWI loco, OSNsTEST. PATHS  

//FTb^FOOi  OU  UNI T»01SK,0ISP*SHR, 

//  VUL  = StKsRJIijC,0,03NsTt SI  .final 
//FIbOFOOl  DO  uM  r*OISK,r)lSP*SMR, 

//  VuLsSLHsKIIOCO.oSNsltSI.IfcMPbO 
//FlblFOOl  00  OISPsSHR.OSNsMI  I .Cai.PUS230,JVJO,TEST,«eSOU«C£. 

//FT70F001  DO  UNI r=OlSK,OlSPs(,OLLkTt),  • - 

//  SPAC6.s(  IW'*  ( 10.  10)  ,kLSF  ) » 

//  DCBs(WECFi4svttS,LPELL=l60»,HLKSIZtal  1^60) , 

■ //  OSNslllliTtMP70  

//FT71F0O1  00  UNI rsOlSK.OlSPsI.DtLLTL), 

//  SPACtalTPR, 1 10, 10) ,RLSr  ; , 

//  UCb=(WCCFN  = vdS.LHLCLalfi08,ULKSUtslUb0) . ...  . ... 

//  DSNSMTEMP71 

//FTROroOl  00  UNI l50I3K,DISPs(, DELETE)  , 

//  SPACLsI IKK, ( 10, 10) ,KLSE ).  - 

//  OCBs(KECFM  = vuS,LkELL*lhO«,ULRSUtsU«JbO) , 

//  OSNsimTEMPftO 

//FTfliroOl  UO  UNI tsOISK,OISP*(, DELETE),  - 

//  SPACEsIlHR,  UO,  10),HLSF), 

//  OCB=(RECFMsVfJS,LHECLsibOb,HLKSUtsl  I2b0), 

//  0SN=&4TEMP«I  - . • - - 

//FT9)F001  OU  UNI IsuISK,niSP*SHR, 

//  VUL*SER=HTIUCO,0bNxltSI .ApHnuN 

//FT9^F00l  00  UNI  |sOIS'',OISPsSHW, 

//  VUL  = SEHsMrU'tl),0oN  = TEST.eC)lJN2B 
//FTRiFOOi  00  Ui4l  1 sOISK.DISPsShR, 

//  VOLsSEHsHIiUCO.USNsTFST.OIST 
//FT9UF001  00  UNl r=01SR,01SP»SHH, 

//  VOLsSEHsHl lUCU.OSNsIEST, rVLWEC 

//SYSIN  00  * ..  


Figure  10.  Job  Control  Language  Statements  for 
Transportation  Subsystem  Tests 
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Figure  11.  Control  Records  for  Trial  Run 


another  table  in  which  the  number  of  time  periods  (loops)  in  each  system  run 
will  be  stated  explicitly.  In  this  concept,  the  scenario  is  managed 
interactively.  At  this  time  it  is  apparent  that  under  this  concept  the 
person  responsible  for  the  interactive  session  should  have  some  intermediate 
outputs  which  will  enable  the  optimum  usage  of  the  run  controls.  However, 
this  need  has  not  been  studied  sufficiently  to  recommend  specific  inter- 
mediate output  requirements. 

A review  of  Figure  4 shows  the  need  for  various  sort  orders  for  files 
between  program  execution.  The  DCPASORT  program  described  in  Appendix  B was 
created  to  provide  a highly  flexible  method  by  which  any  of  the  files  may  be 
sorted  within  the  system  context. 

While  the  resident  main  module  in  the  overlay  structure,  called 
DCPAMAIN,  was  created  on  the  IBM  370/165,  no  unwarranted  effort  will  be 
required  to  convert  the  control  procedures  operational  at  the  Triangle 
Universities  Computation  Center  (TUCC)  to  the  UNIVAC  system  operational  at 
DCPACC.  This  problem  is  addressed  in  the  next  subsection. 

D.  ConversiQ.n  to  the  UNIVAC  1100/10  Computer 

The  LEMOS  system  was  implemented  on  the  IBM  370/165  located  at  TUCC. 

The  total  package  of  programs  requires  a large  number  of  files  and  many 
executable  "steps"  on  the  IBM  computer. 

The  conversion  of  the  LEMOS  system  to  the  UNIVAC  110/10  computer 
appears  to  be  quite  simple  with  the  9ASG  and  the  @US£  executive  commands 
being  used  specifically  to  define  the  files.  The  9A0D  command  can  be  used 
to  evoke  a series  of  9ASG's,  9C0B*s,  eXQT's,  and  BMAP's  to  create  and  merge 
the  program  elements  into  executable  absolute  modules  and  then  execute  the 
proper  module.  Other  9A00  commands  are  also  used  to  supply  run  parameters. 

Since  the  UNIVAC  ASCII  COBOL  compiler  system  also  contains  all  the 
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space  economizing  elements  utilized  In  the  development  of  the  LEMOS  programs 
(such  as  the  overlay  and  COPY  features),  no  significant  program  modifica- 
tions are  envisioned  In  the  conversion  process. 
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The  relatively  large  number  of  files  used  by  the  LEMOS  system  requires 
special  attention  to  file  management  so  as  to  minimize  I/O's  and  their 
Impact  on  running  time  and  cost.  There  are  seventeen  potential  program 
runs,  and  there  are  forty -one  files  that  must  be  maintained  during  these 
runs.  During  the  contract  period,  RTI  attempted  to  minimize  the  total 
number  of  files  used  and  the  number  used  in  each  program  run.  Moreover, 
each  program  was  examined  with  the  view  of  Incorporating  some  of  the  File 
and  Working  Storage  Sections  In  a Library  (OCPALIB)  rather  than  In  each 
program.  Communication  between  programs  Is  discussed  In  the  next  subsection 
and  a concise  report  on  file  names  and  descriptions  are  described  In  the 
last  subsection. 

B.  Interproqram  Communication 

Two  types  of  communications  occur  between  programs.  Type  one  Is 
referred  to  as  control  data  and  Is  resident  In  the  main  program.  Type  two 
Is  a file  record  that  Is  read  Into  or  written  from  working  areas  within  the 
program.  Changes  to  values  in  fields  within  this  record  Is  the  most  common. 
Either  of  these  types  of  communications  may  be  displayed  at  a CRT  or  printed 
as  user  Information.  Type  two  communications  may  be  further  subdivided  Into 
those  which  pass  between  programs  within  a single  pass  and  those  \4i1ch 
transmit  Information  between  passes.  The  former  are  considered  more 
transitory,  and  In  some  Instances,  permit  the  same  file  Identity  to  be  used 
more  than  once  In  one  simulated  time  period. 

Figure  12  shows  the  current  Input-output  relationships  between  LEMOS 
files  and  the  programs  which  use  them.  While  the  present  file  Identities 
are  adequate.  It  Is  evident  that  further  reductions  In  the  number  of 
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Figure  12. 
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Identities  can  be  made  with  some  gains  In  off-line  storage  space.  However, 
changes  to  obtain  these  marginal  gains  would  be  somewhat  premature.  Since 
the  prototype  TELOS  system  has  not  been  tested,  such  refinement  should  wait 
until  LOCATE,  ADS,  and  LEMOS  are  placed  under  control  of  the  DCPAMAIN 
described  In  Section  II. 

The  field  descriptions  of  the  type  one  communications  (scenario  or 
DCPAMAIN  control)  are  described  In  Appendix  C.  Files  Identified  In  Figure  12 
are  described  briefly  In  the  next  section  to  convey  to  the  reader  the  type  of 
information  transmitted  In  Interprogram  communications. 

C.  File  Descriptions 

Figure  12  Identifies  all  files  used  by  name  code  or  acronym  (DDNAME); 

however,  the  descriptions  In  this  section  will  be  Identified  by  the  basic 

name  In  the  description  column.  The  following  files  are  described  briefly 

In  subsequent  paragraphs.  More  specific  definitions  of  fields  In  these 

records  are  contained  In  Appendix  D. 

0 Reference  (REFERENCE) 

0 Master  Status  (MASTER! -2) 

0 Problem  (PROBl-3) 

0 Resource  (RESOURCE! -2) 

0 Organization  (ORGN) 

0 Service  (SERVICEl-2) 

0 Operations  (OPSl-2) 

0 Assignment  (ASGNl-4) 

0 Trip  (TRIP) 

0 History  (HISTORY) 

0 Performance  (PERFORMANCE) 

0 Plot  (PLOT! -2) 

0 Benefits  (BENEFITS) 

0 Links  (LINKS) 

0 Travel  (TVLREF) 

The  Reference  File  contains  a series  of  tables  v*1ch  represent  basic 
reference  material  (on  operations,  functions,  and  teams)  required  to 
quantify  the  simulated  operations.  An  Alternative  Table  produces  a set  of 
alternative  operations  given  a specific  problem.  The  Operations  Table 
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defines  the  specific  functions  which  constitute  the  operation.  A Function 
Table  indicates  the  teams  which  can  perform  that  function  together  with 
their  relative  efficiency.  The  characteristics  of  each  team  are  contained 
in  the  Team  Table,  which  along  with  the  Work  Table,  enables  the  user  to 
compute  team-hour  and  resource  requirements  for  functional  performance  to 
resolve  problems.  This  file  may  be  modified  at  the  beginning  of  a simulat- 
tion,  but  should  not  be  changed  during  the  time  frame  of  the  scenario. 

The  target  model  is  contained  in  the  tiaster  Status  File  (MSF)  in  terms 
of  area,  structures,  shelter,  people,  and  other  special  resources.  Each  of 
these  elements  is  classified  by  types  and  status.  Quantities  in  the  MSF 
record  fields  are  changed  in  the  Area  Damage  System  (ADS)  model  to  reflect 
target  degradation.  The  object  of  the  LEMOS  model  is  to  upgrade  resource 
states  using  various  functional  countermeasures,  or  at  least  to  prevent 
further  degradation  by  fire  and  fallout.  This  file  is  a primary  communica- 
tion vehicle  between  ADS  and  LEMOS  and  between  time  periods.  At  the  present, 
time,  ADS  has  not  been  modified  to  process  the  special  resources  portion  of 
the  MSF. 

When  LEMOS  receives  the  MSF  from  ADS,  it  redefines  the  target  in  terms 
of  two  files,  namely,  the  Problem  File  and  Resources  File. 

The  purpose  of  the  Problem  File  is  to  define  explicitly  problems  by 
unit  area  which  must  be  resolved  by  the  available  countermeasures.  Four 
general  problem  types  are  recognized:  control,  readiness,  damage,  and 
relief  and  rehabilitation.  The  objective  of  local  operations  is  to  resolve 
each  of  these  problems  as  soon  as  practicable. 

The  Resource  File  quantifies  the  resources  by  unit  area  and  provides  a 
means  for  accounting  for  the  essential  elements  of  the  MSF  during  counter- 
measure processing.  Emphasis  is  placed  on  tracking  personnel  and  CD  teams. 
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After  both  the  Resource  and  Problem  files  have  been  modified  during  the 
course  of  processing  by  the  LEMOS  system,  a revised  MSF  Is  generated  In  the 
Inventory  Protection  Program  (PGM9)  and  returned  to  AOS  for  new  damage 
estimation  as  a result  of  more  weapons,  fire  spread,  or  fallout. 

An  Organization  File  has  been  Introduced  as  a part  of  the  system,  but 
virtually  no  use  Is  made  of  It  In  the  absence  of  a communication  model.  The 
purpose  of  this  file  Is  to  assign  areas  and  teams  to  specific  Civil  Defense 
organizational  structures.  Since  communication  Is  considered  perfect  and 
without  any  capacity  constraints,  this  file  does  not  serve  a particular 
purpose  at  this  time. 

The  Service  File  Is  required  to  maintain  Information  about  the  teams 
and  the  services  to  ti^lch  the  teams  belong.  It  Is  used  In  the  Requirement 
Program  (PGM2)  to  define  readiness  problems.  The  status  of  each  team  Is 
determined  in  the  Operations  Program  (PGM7).  This  represents  a primary 
feedback  on  the  status  of  Civil  Defense  teams. 

From  the  Requirements  Program,  two  files  (Operations  and  Assignment) 
relay  Information  to  the  Assignment  Subsystem  about  viable  problem 
solutions.  The  Assignment  Subsystem  Is  designed  to  select  from  among  three 
alternatives  the  specific  operations  to  be  undertaken  later  In  the  Opera- 
tions Program. 

The  Operations  File  contains  a record  for  each  selected  operation  In 
terms  of  the  specific  functions  needed  to  resolve  the  problem.  In  addition, 
this  record  contains  Information  about  quanititles,  start  time,  benefits, 
priorities,  and  related  subjects.  i . 

Each  function  Is  represented  by  a record  In  the  Assignment  File  on  I 

which  the  operation  Is  Identified,  the  number  of  teams  assigned,  the  start  I 

time  determined,  and  the  amount  of  effort  expressed  In  team-hours  to  produce 

i 


I 


the  desired  result. 

Where  movement  of  resources  (including  people  requiring  aid,  or  CD 
teams  and  material  to  provide  aid)  are  required,  trip  records  are  prepared 
giving  origin  and  destinations  as  well  as  start  and  arrival  times.  Two 
records  are  prepared  In  the  Deployment  Program  (PGM6),  one  for  the  unit  area 
In  ifi^ilch  the  move  originates,  and  the  second  for  the  unit  area  In  which  the 
move  terminates.  After  sorting  between  Program  6 and  7,  these  records  are 
used  to  subtract  resources  from  one  area  and  to  add  another  area  to  accom- 
plish the  deployment.  The  Trip  File  contains  enlarged  records.  The  trip 
record  merges  the  assignment  record  with  operation  and  trip  data  to  minimize 
the  problem  of  matching  trips  to  assignments  and  operations. 

The  assignment  or  trip  records  are  completed  In  the  Operations  Program 
(PGM7)  by  expending  resources  and  deriving  benefits.  These  transactions  are 
recorded  on  the  assignment  records  and.  If  desired,  retained  for  historical 
analysis.  All  retained  assignment  records  are  contained  In  the  History 
File.  In  most  cases,  the  History  File  Is  not  retained.  However,  benefits 
and  team  readiness  data  Is  retained  In  the  Performance  File  and  becomes  the 
basis  for  report  generation. 

Performance  data  from  the  Performance  File  Is  analyzed  In  the  Report 
Generator  and  tabular  Benefit  and  Readiness  Reports  prepared  In  the  Report 
Generation  Program  (PGM8).  Values  of  key  performance  measures  are  retained 
from  these  reports  In  the  Plot  File  for  time  plots  at  designated  breaks  In 
the  scenario  or  Benefit  File.  Normally,  these  breaks  occur  when  Interactive 
sessions  are  planned  to  evaluate  Intermediate  results  and,  perhaps,  change 
priorities,  prohibitions,  or  llmitlons  used  to  control  the  scenario. 

Two  significant  files  have  not  yet  been  described.  They  are  the  Links 
File  and  Travel  Reference  File  and,  respectively,  are  used  as  Input  to  and 
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output  from  the  Transportation  Subsystem.  They  are  noted  among  the  FORTRAN 
files  at  the  bottom  of  Figure  8.  While  other  FORTRAN  files  are  used  In  the 
Transportation  Subsystem,  they  are  used  as  working  files  between  programs 
within  it.  The  FORTRAN  Resource  File  (FT61F001)  Is  also  the  COBOL  Resource 1 
File  {FILE4)  and  the  FORTRAN  TVLREF  File  (FT94F001)  Is  also  the  COBOL  TVLREF 
(FILE22).  Using  these  renaming  conventions,  the  Transportation  Subsystem  Is 
Integrated  Into  the  LEMOS  system. 

The  Links  File  contains  Information  about  the  highway  system  by  which 
unit  areas  are  linked  and  over  which  resources  are  moved.  The  damage 
assessment  system  does  not  process  this  file  at  the  present  time.  However, 
provision  should  be  made  at  a later  date  to  determine  damage  to  the  highway 
network  (particularly  to  bridges  In  It).  Nevertheless,  some  consideration 
Is  given  to  weapons  effects  by  using  the  Basic  Operating  Situation  (BOS) 
designations  from  the  Resource  File.  The  analysis  of  the  transportation 
network  by  Floyd's  algorithm  leads  to  the  preparation  of  the  Travel  Refer- 
ence File  containing  measures  of  average  travel  time  between  all  origins  and 
destinations  In  terms  of  unit  areas.  These  reference  travel  time  values  are 
used  to  select  assignments  In  the  assignment  subsystem  and  prepare  trip 
records  In  the  Deployment  Program.  Redefinition  of  this  file  depends  on 
changes  In  the  BOS  for  each  unit  area.  However,  It  may  not  be  necessary  to 
redefine  It  for  each  time  period  unless  significant  changes  have  occurred 
(e.g.,  another  weapon  detonates  or  severe  environmental  changes  occur  In 
many  unit  areas). 

The  above  descriptions  of  the  files  used  by  LEMOS  under  DCPAMAIN  are  not  ' 

detailed  but  should  serve  to  create  a more  coherent  view  of  the  Interconnec- 
tions between  LEMOS  modules.  A more  detailed  but  less  comprehensive  view 
can  be  obtained  by  reviewing  the  record  format  descriptions  In  Appendix  0. 

I 
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Future  work  should  attempt  to  further  reduce  the  »nount  of  data  commu- 
nicated between  programs  as  a means  for  minimizing  core  memory  requirements 
(under  each  overlay  branch)  and  system  running  time.  Each  record  field  In 
all  files  should  be  reviewed  for  Its  contribution  to  the  overall  evaluation. 
This  review  cannot  be  undertaken  until  ADS  and  LEMOS  are  effectively  Inte- 
grated under  DCPAHAIN. 


IV.  DISCUSSION  AND  CONCLUSIONS 


The  main  accomplishments  during  the  contract  period  were  the  develop- 
ment of  the  executive  control  (OCPAMAIN)  for  LEMOS  (and  for  TELOS  as  well) 
and  Improved  management  of  Interconnecting  files.  The  overlay  structure 
approach  In  OCPAHAIN  (perhaps  better  called  TELOSMAIN)  appears  after  study 
to  be  compatible  with  the  UNIVAC  1100/10  at  DCPACC.  Therefore,  all  COBOL 
and  FORTRAN  programs  at  TUCC  (Including  OCPAMAIN)  should  be  converted  to 
operate  on  the  UNIVAC  1100/10  at  DCPACC  without  further  major  modification. 

Scenario  definition  and  output  requirements  (both  printed  and  CRT 
Displays)  require  additional  study  to  ensure  that  TELOS  will  accomplish  Its 
research  objectives. 

After  conversion  and  scenario  review,  OCPAMAIN  should  be  modified  to 
provide  Improved  scenario  controls  Including  Interactive  update  of  the 
reference  files,  cyclical  period  controls  between  manual  Interventions  with 
variable  times  per  period,  matrix  modification  of  program  control  fields 
used  In  each  cycle,  and  variable  selection  of  programs  on  successive  cycles. 

Other  modifications  will  undoubtedly  evolve  as  a result  of  the  scenario 
study  and  need  to  be  Included  In  the  system  as  the  opportunity  arises. 

Concurrent  with  conversion  of  LEMOS  programs  to  the  UNIVAC  system,  the 
AOS  programs  should  be  modified  to  assess  damage  to  special  CD  resources. 

Including  damage  to  highway  bridges  for  the  Transportation  Subsystem.  Since 
the  countermeasures  model  relies  heavily  upon  the  transportation  network, 

I 

the  Links  File  should  be  processed  by  AOS  as  well  as  the  NETWORK  program  In  > 

i 

the  Transportation  Subsystem.  ] 

When  LEMOS  Is  converted  to  operate  on  the  equipment  UNIVAC,  GENUA, 

LOCATE,  and  AOS  should  be  brought  Into  the  overlay  structure  so  that  the 
TELOS  system  will  be  essentially  complete.  Once  the  overall  structure  Is 
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prepared,  runs  can  be  executed  to  validate  the  accuracy  of  each  program.  In 
order  to  facilitate  this  validation  process,  an  accounting  program  should  be 
written  and  appended  to  OCPAMAIN.  This  program  would  select  certain  sets  of 
Input  fields  for  comparison  with  corresponding  sets  of  output  fields. 
Comparisons  of  this  type  **111  aid  In  detecting  program  errors,  especially 
roundoff  errors  which  would  be  difficult  or  time  consuming  to  find  otherwise. 
When  all  significant  errors  have  been  purged  from  the  system,  comprehensive 
scenario  tests  must  be  planned  to  establish  the  capablltles  of  the  TELOS 
system  and  determine  the  effectiveness  of  the  system  In  performing  the 

r 

various  roles  It  may  play  either  for  research  or  for  plans  and  operations. 
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V.  RECOMMENDATIONS 


I 
I 

^ RTI  recommends  that  the  LEMOS  system  be  converted  from  the  IBM  370/165 

I at  TUCC  to  the  UNIVAC  1100/10  at  DCPACC.  After  conversion,  the  following 

developmental  tasks  should  be  undertaken. 

0 Determine  scenario  Input  and  report/display  output  requirements. 

0 Integrate  GENUA,  LOCATE,  AOS,  and  LEMOS  under  the  same  executive 

control  using  overlay  or  virtual  memory  procedures. 

0 Enable  AOS  to  assess  special  CO  resources  and  network  link  damage. 

0 Coordinate  processing  between  AOS  and  LEMOS/operatlons  model  to 
prevent  over  or  under  estimation  of  Injuries  and  deaths. 

I 0 Develop  an  accounting  monitor  to  debug  the  TELOS  system  and 

- perform  extensive  testing  to  evaluate  system  capabilities. 

I 

I 

1 


r 

I 

I 

1! 
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PWoGHAM-lp.  'Pii^l', 

LNvlWUNWLM  DIVISION. 
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► lLt-CUNT«UL. 

SLLtCT  CAUD-FILE  assign  TU  UT-S-SYSIN. 
StLtCt  PWINT-HUt  ASSIGN  TU  UT-S-SYSPRINT . 
UAIA  division. 
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FO  PKINI-FILF  BEtUHOING  MODE  IS  F LABEL  RECORDS  ARE  OMIfTEO 
HtCUKD  contains  133  CHARACTERS  DATA  RECORD  IS  PRINT-RECORD. 
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02  Cr.  . PICTURE  X, 

02  »'R|NT-AhEA  picture  X(132). 

FU  CAWU-FRt  recording  MODE  IS  F LABEL  RECORDS  ARE  OMITTED 
RECORD  CONTAINS  BO  CHARACTERS  BLOCK  CONTAINS  0 RECORDS 
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02  filler  PIC  X(80).  _ _ _ _ 
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lsy.  pic  s9(4)  comp  sync. 

CunIKOL-CARD, 

02  C-SNO  PIC  9.  ■■ 

Ot  filler  PlC  X(7). 

02  WUM-Sw  PIC  X, ...  . 

02  TESTSK  pic  X. 

02  A-S(v  PIC  9. 

02  U-S’.:i  PIC  9. 

02  L-Si«  PIC  9. 

02  0-S.N  PIC  9. 
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02  bURT-Nfj  PIC  9. 

OATE-CAkO  COPY  'UAIECARD', 
DATE-CARD. 
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02  PERIOD.' 
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COMP  SYNC. 
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OOl.OU 

00105 

0010b 

00107 


02  8US-LEVFL2  PIC  “99.  _ 

02  rt()S-LPVEL3  PIC  V9V, 

02  iillS-LEVELa  PIC  V99, 

02  DLHMlS-LtVEL  PIC  9V9  UCCUHS  5 TIMES, 

02  PULlCr-2  PIC  9. 

02  2UM-N11MHEH  PIC  9V9, 

02  TILLLW  PIC  X(2i), 

02  POM-StO  PIC  99, 

02  Nii-DAT4-CAflUS  PIC  999, 

02  HTPASS-CONTHUU  pic  9, . . 

02  tOMM-LUOF  PIC  9, 

02  PUSTUKE-CUOE  PIC  99. 

02  c App-cuDE  _ej CJJ . . 

// 

OOObOU  PPDCEDUPb  DIVISION. 

OoOblO  SIART-PtiM, 

IJlSPLAV  'STAHl-tXtC-WESMAllJ', 

000620  (IPtO  INPUT  card-file, 

OlSPLAy  'opened  card-files  

KtPEAl-LUMTHOL, 

REAP  card-file  INTO  CONTROL-CARD  AT  END  tO  TO  STOP-RUN. 
DISPLAY  'CONTROL-CARD  ' CUN TROL-C ARp, 

IE  HU\-Sw  s 'X'  DO  TO  STOP-RUN, 

IF  PON-Sk*  s 'M' 

PERFORM  SORT -■•'ASTER  JMRU  SUB  T-MASTER-END. 

IF  RUN-Srt  = 'P' 

PEhFORM  SDRT-PRUd  THRU  SUR T -PROB-ENP 
C.U  ?U  REPEAT-CONTROL. 

IF  RUN-Si*  = 'R' 

PLk'FORm  SORI-HESt  THRU  S(JHT-HESC-ENl) 

DO  TU  REPEAr-CONIHUL. _ _ _ 

IF  KUN-Sw  s’'l'  

PERFORM  READ-OATE-CARP 

perform  RUN-l  THRU  HUN_-l-£NO, 

IF  RUfl-Si(  s '2'~ 


PEPFfIKM  PF  Ap-DAT  E-CARp 


IF 

IF 

IF 

IF 

IF 

IF 


CALL 
GO  TO 
A-SH 
h-SH 
L-Sr, 
P-Sr; 
t-SR 
RUN- 
00  VF. 
CALL 
PISPL 

r.'i.iVE 

CALL 

PISPL 


0 TO  A-S8. 
MOVE  0 TO  fl-Srt, 
TO  C-S*v. 
TO  P-Sw. 
TO  E-Srt. 


'wr.MP'  USING  PAIE-CAHP 

repeat-cumrul. 

NOT  NU^IERIC  MOVE 
NOT  NUMERIC 
NUT  VtjMtRIC 
NOT  NUMERIC 
NOT  NUMERIC 
SR  s '3' 

A-SW  TO  A3W 
'NGM3A'  USING  ASr 

AY  » £NP-ExEC-OF-PGMsNETrORK 

H-Sr  TU  USrt 
'NGMSfl'  USING  bS« 

AY  • END-txEL-OF-PGM*ALLNET 


MOVE 

MOVE 

MOVE 


MuvF.  c-sr  to  CSR 
Call  'MGM3C'  USING  CSW 

display  ENP-tXf.C-UF-RGMsPAMAGE 
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nUVt  rj  fcSi4 
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GO  TO  HEPEAT-CONTHUL, 

IF  WUN-Si»'  = 

MUVF  8-Sw  TO  8SW 

call  *NGM5B' USING  bSw 

display  '**»*«  FlNISH-tXtC-ALLNET 
GO  TO  HEPEAT-CONTHOL. 

IF  MUN-3<*  s 'C' . 

■»OVk  t-S<»  TO  CSw" 
call  *NGM5C'  using  CSrt 

display  '»»••»  FlNlSH-tXEC-OAMAGt  . * « • * 
r.U  TO  kEPEAT-CONTHUL. 

IF  hUN-S*i  s '0' 


MUVr  O-SK  T0.DS6  . 
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GO  TO  REPEAl-CUNTkOL, 
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SI  UP-RUN, 
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00185 

OUU600 

CLUSE  card-fill. 

0016b 

SI  UP  RUN. 

00167 

bURI-MASIER. 
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'^UVt  5 10  SORT-NU. 
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DISPLAY  'CALLING  DCPASURT'. 

00190 

CAll  'DCPASORT'  USING  SUR T -CUN TRUL . 

00191 

display  'out  hack  FkijM  DCPASURT'. 

00192 

SuRl— .ASIER-ENU.  EXII. 

00193 

SURT-PRUIi. 

00194 

MUVE  b TU  SORI-NU. 

0019S 

LALL  'OLPASORT'  USING  SURl -CON  I ROL . 

0019b 

SuPl-PRUK-ENO.  EXif, 

00197 

SUR I -R1 SC  , 

00196 

‘AfJVE  7 TO  SORI-NU. 

00199 

LALL  'OCPASORI'  USING  SORT -CUNT RUL . 

00200 

SijHt-RESC-END.  EXIT. 
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APPENDIX  B 


OCPASORT  PROGRAM  LISTING 


_0000l  OOOOlO  IDtNlIFlCATIUN  DIVISION. 

00002  ■ OOOOiO  PHOOHAM-IO.  'DCPASUMt*. 

"OOOOi  00003o  CNvlPUN'IfNT  DIVISION, 

00004  000040  INPUT-OUTPUT  SECTIUN. 

“00005~  000050  F ICE-CUNTWOL. 

00006  SELECT  CAPD-PILE  ASSIGN  TU  UT-S-SVSIN, 

_00007  SELECT  old-master  ASSIGN  TO  UT-S-FILE5, 

TIOOOd  SELECT  NE«-masTER  ASSIGN  TU  UI-S-HLE2. 

00000  select  FILE-J  assign  to  UT-S-FILE3. 

00010  SELECI  file-4  ASSIGN  TU  UT-S-F1LE4. 

0001  1 SELECT  FlLt20  ASSIGN  TO  UT-S-FILE20. 

00012  SELECT  FILE21  ASSIGN  TO  UT-S-FILE2I. 

00013  _ SELECT  FILE26  ASSIGN  TO  UT-S-FILE26. 

“00014"  SELECT  SOKT-MAST  ASSIGN  TU  UT-S-SOHTwKOl 

^00015  UT-S-SORTWK02 

00016  UT-S-SOPTAK03. 

“OOOir'  SELECT  SOPT-ASGN  ASSIGN  TO  UT-S-SORTttKO 1 

OOOie  UT-S-SORTMK02 

00019  UT-S-SORTWR03. 

00020  '■  - SELECT'SOHT-PROU  ASSIGN  TO  U I -S-SOWTNKO 1 

*00021  UT-S-SORrKR02 

00022  uT-S-SURThk03, 

“D0023*‘  SELECT  SURT-RESC  ASSIGN  lu  UT-S-SOHTwh01 

00024  UT-S-SOWTWK02 

00025  UT-S-S0HTRK03. 

“00026  000100  data  division. 

*00027  000110  file  SECTION. 

“00028  000210  FD  CAkO-FlLE  MECUROlNG  MODE  IS  F 

“00029  ~000220  **  RECORD  CONTAINS  60  CHARACTERS  BLOCK  CONTAINS  0 

00030  000230  DATA  RECORD  IS  CARD-RECORD. 

00031  01  CARD-RECORD. 

“00032  02  FILLER  PIC  X(60),  * 

_00033  ' SO  SORT-ASGN  DATA  RECORD  ASGN-RtCORD. 

00034'  01  ASCN-RECORO. 

“00035  02  filler  PIC  X(16). 


LAbEL  RECORDS  ARE  OMITTED 
RECORDS 


00036 

00037 
"00038  " 

00039 

"00040 

00041 

00042 

00043 

"00044 

■ 00045 

' 00046 
"00047 

00048 

00049 

"00050 

*00051 

"00052 


02  UPERATION-NO. 

03  FILLER  PIC  X(08). 

03  ()P-PHTV  PIC  99. 

03  filler  pic  X(05). 

02  filler  pic  XCOl). 

02  team  pic  99. 

02  filler  pic  X(02J, 

02  EUC  PIC  99. 

02  filler  pic  x(02). 

02  UG-PRTT  PlC  99. 

02  filler  PlC  XlllO). 

02  initial-priority  pic  99V9, 

02  filler  pic  X(»5I. 

SO  surt-mast  data  record  mast-record. 
01  mast-record. 

02  .‘lAST-CnOE  PICTURE  9. 

02  .MAST-SuB-TYPE  PICTURE  9. 


BET  AVAIIA 


r>’  r 


B-2 


00053 

02  filler  PlCtUHE  *109). 

“0005a  - 

• 

02  MAST-UA-CODE  PICTURE  X(6). 

00055 

02  MAST-LUC-CODE  PIC  X(08). 

00056 

02  filler  picture  X(63). 

■00057 

1-D 

old-master  recording  mode  f label  records  standard 

0005B 

record  contains  88  CHAWACIERS  BLOCK  CONTAINS  aO  i 

RECORDS 

00059 

DATA  record  OLO-MASTER-RECORU. 

“00060  “ 

01 

OLD-MASTER-RECORO. 

00061 

02  filler  pic  X(88). 

00062 

H) 

NEm-MASTER  recording  mode  f label  records  standard 

00063 

RECORD  CONTAINS  88  CHARACTERS  BLOCK  CONTAINS  aO  1 

RECORDS 

00060 

DATA  record  NEm-MASTER-RECORD. 

00065 

01 

NEm-masTER-RECORD. 

“00066 — 

02  filler  pic  X(88J.  “ 

0006/ 

so 

sort-prob  data  record  prob-record. 

0006B 

01 

PROb-RECORD. 

“00069  ■ ■ 

OJ  PHOB-AREA  PlC  X(6),  ■ 

00070 

02  PHOR-LINK  PIC  X(2). 

“00071 

* 

02  PfiOR-LUC  PIC  X(2). 

“00072 — 

02  PROR-CLASS  PIC  X. 

00073 

02  filler  PIC  XC59). 

0007a 

Su 

SOWI-RESC  DATA  RECORD  RESC-RECORD. 

“00075  ■ 

01 

RESC-RFCORD. 

■00076 

02  RESr-AREA  PIC  X(6). 

-00077 

02  RESC-LINK  PIC  X(2). 

“00078 

02  RESC-LUC  PIC  X12). 

00079 

02  filler  PIC  *(119). 

00080 

► 0 

FILE-3  recording  mode  F label  records  STANDARD 

“00081 

RECORD  CONTAHS  070  CHARACTERS  BLOCK  CONTAINS  aO 

RECORDS 

00082 

DATA  RECORD  RECURD-3. 

00083 

Ul 

RtCURO-5  PIC  X{70). 

0008a  ■■ 

► u 

FlLE-'l  RECORDING  MODE  F LABEL  RECORDS  STANDARD 

00065 

RECORD  CONTAINS  129  CHARACTERS  SLOCK  CONTAINS  20 

RECORDS 

00066 

DATA  RECORD  HECORD-a. 

'00067 

01 

RECURD-a  PIC  X(129). 

“00088 

FO 

FILE20  RECORDING  MODE  F LABEL  RECORDS  STANDARD 

00089 

RECORD  CONTAINS  290  CHARACTERS  BLOCK  CONTAINS  20 

RECORDS 

“00090 

" — — •••  - 

DATA  RECORD  REC20.  ' 

00091 

01 

RLC20  PIC  X(2ao). 

0009^ 

FO 

FILE21  recording  MODE  F LABEL  RECORDS  STANDARD 

“00095 

RECORD  CONTAINS  290  CHARACTERS  BLOCK  CONTAINS  20 

RECORDS 

0009a 

DATA  RECORD  REC21. 

00095 

01 

REC21  PIC  X(2a0). 

“00096  - 

- --  FD 

F1LE26  RECORDING  MODE  F LABEL  RECORDS  STANDARD 

00097 

RECORD  CONTAINS  290  CHARACTERS  BLOCK  CONTAINS  20 

RECORDS 

00098 

OAIA  RECORD  ReC26. 

“00099  “ 

01 

REC26  PIC  ■<(290).  • 

00100 

000290  W()»Ki;jO-STnBACE  SECTION. 

00101 

LINKAGE  SECTION. 

*00102— 

01 

SORT-CONTROL. 

00103 

02  SORT-NO  PIC  9. 

ooloa 

02  filler  pic  X(79). 

“00105 

000600  PROCEDURE  DIVISION  USING  SORT-CONTROL. 

- 00106 

000610  STAMl-PtiM. 

00107 

MOVE  100000  TO  SOMT-CORE-SlZt. 

BESrA'ii;;.. 
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00106 

IF  60HT-N0  NUT  UUMLKlC 

~00109“ 

OISPLAV  'SU«T-N0-NUT-N0M£«IC*  ABOMTfO' 

00110 

CO  TO  RETUHN-3TEP, 

00111 

CO  TU  SKI  SR2  3K3  SK4  SK5  SKb  SR7  SK6  SK9 

"00112 

DkPENOING  On  SOKT-NO. 

OOlli 

SHI. 

00114 

SUHI  SOHT-ASCN  ON 

"00115 

ASCENDINC  KEY  TEAM 

0011b 

ASCENDING  KEY  INITIAL-HHlOHITY 

00117 

USl-NG  F1LE20 

"00116 

GIVING  FILE20. 

00119 

GO  TO  HETUHN-STEP, 

'00120 

SR2. 

"00121  ■ 

SORT  80RT-ASCN  ON  " 

00122 

ASCENDING  KEY  UHEHATION-NU 

00123 

USING  FILE21 

"00124 

GIVING  FILE21. 

00125 

GO  TO  HETUHN-SItP. 

"0012b 

SR3. 

"00127  

S09T  SORT-ASCN  ON 

00126 

ascending  key  up-phty 

00129 

USING  FILE20 

"00130  "■  • 

GIVING  FILE20. 

■ 00131 

GO  TO  RETURN-STEP. 

"00132 

SR4. 

"00133  

SOHT  SORT-ASGN  ON 

00134 

ASCENDING  KfT  EuC 

00135 

ascending  key  op-phty 

"00136 

USING  FIcFPb 

00137 

GIVING  F|lE2o. 

■ 00138 

GO  TO  HETuh»  step. 

"00139 “ 

SR5. 

00140 

suHi  sPRi-KiAsr  UN 

00141 

ASCENDING  KEY  M*sr-UA-CUOL 

"00142 

ASCENDING  KEY  mast-code 

■■00145 

ASCENDING  kF.Y  maST-SUS-TYFE 

"00144 

ASCENDING  KEY  M*sr-LUC-CODE 

"00145  * 

USING  Old-master 

00146 

GIVING  NEy.-maSIEH. 

00147 

GU  TO  HF.TUKN-STEP, 

"00148 

SH6. 

■ 00149 

SORT  SOKT-PRCta  (Jfl 

00150 

ASCENDINC  KEY  PROb-AREA 

"00151 " 

ASCENDING  KEY  PRue-LJC 

00152 

ASCENDING  key  PHU6-CLASS 

00153 

USING  file-3 

"00154 

GIVING  FICE-3. 

00155 

GO  TO  RETURN-STEP. 

"00156 

SH/. 

"00157 

SQPT  SriRI-RESC  ON 

00156 

ASCENDING  KEY  HESC-AREA 

00159 

ASCENDING  key  RESC-LUC 

"00160  

USING  FU.E-4 

00161 

GIVING  FIlF-4. 

"00162 

GO  TO  RETURN-STEP. 
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DCPA  MAIN  RUN  CONTROLS 

0 Hours  from  beginning  of  scenario. 

0 Duration  of  current  period.  In  hours. 

0 Sequence  number  of  current  period. 

0 Flag  to  Indicate  whether  or  not  there  was  a previous  period. 

0 Code  for  minimum  PF  level  for  shelter  spaces  to  be  used. 

0 Code  for  maximum  floor  height  (above  ground)  for  shelter  spaces 

to  be  used. 

0 Low  radiation  level  (RADS)  for  defining  the  basic  operating 
situation  (BOS). 

0 High  radiation  level  (RADS)  for  defining  BOS. 

0 Low  fire  level  (fraction  of  area  aflame)  for  defining  BOS. 

0 High  fire  level  (fraction  of  area  aflame)  for  defing  BOS. 

0 Codes  for  defining  five  depths  of  debris. 

0 Zone  number  of  area  being  studied. 

0 Level  of  PF  provided  by  being  In  automobile. 

0 Length  of  work  shift,  In  hours. 

0 Fraction  of  casualties  who  are  ambulatory,  for  fifteen  (15) 
Injury  categories. 

0 Maximum  number  of  teams  to  be  assigned  to  one  problem. 

0 Identification  of  sanctuary  area  for  this  zone. 

0 Priority  ranking  of  operations. 

0 Code  to  Indicate  whether  or  not  CD  can  expropriate  resources 
from  residences. 

0 Code  to  Indicate  whether  or  not  population  Is  warned. 

0 Time  of  warning.  If  warned.  (Note:  not  presently  Included) 

0 Weights  used  to  compute  measure  of  effectiveness. 
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APPENDIX  D 


FILE  DESCRIPTIONS 


This  appendix  contains  updated  field  descriptions  for  records  contained 
in  the  following  files: 

A.  Reference  (REFERENCE) 

1.  Team  Table 

2.  Alternative  Table 

3.  Work  Table 

4.  Function  Table 

5.  Operations  Table 

6.  Land-Use  Class  Density  Table 

B.  Master  Status  (MSF) 

1.  Area-Record  Format 

2.  Struc-Data  Format 

3.  Shelter-Data  Format 

4.  Personnel-Status  Record 

5.  Special-Resources  Format 

C.  Problem  (PROB) 

1.  Prob-Type-1  Record 

2.  Prob-Type-2  Record 

3.  Prob-Type-3  Record 

4.  Prob-Type-4  Record 

D.  Resource  (RESOURCE) 

E.  Organization  (ORGN) 

F.  Service  (SERVICE) 

G«  Operations  (OPS) 

H.  Assignment  (ASGN) 

I.  Trip  (TRIP) 

J.  History  (HISTORY) 

K.  Performance 

L.  Plot  (PLOT) 

M.  Benefits  (BENEFITS) 

N.  Links  (LINKS) 

O.  Travel  Reference  (TVLREF) 
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1.  Team  Table 

The  format  for  the  team  table  Is  shown  In  Table  A-I,  T-TABLE  FORMAT 

Table  A-1 
T-TABLE  FORMAT 


COBOL 

COBOL 

Card 

Variable 

Format 

Columns 

Remarks 

Team  Table  continued. 


1.  TEAM-NO-8.  The  identification  number  of  each  team. 

2.  NO-PERS.  The  total  number  of  people  required  in  order  for  the 

team  to  operate. 

3.  FAC  REQMT-CODE.  An  indicator  of  the  requirement  of  a facility  for 

team  operation. 

a.  1 indicates  a facility  is  required. 

b.  0 indicates  a facility  is  not  required. 

4.  PER-SET-NO 

a.  PERS-NO-8.  The  identification  number  of  the  types  of  personnel 
required  for  team  operation — up  to  six  different  types  of 
personnel  allowed. 

b.  NO-PERS-8.  The  quantity  of  people  required  for  each  personnel 
type. 

5 . EQPT-SET-NO 

a.  EQUIP-NO-8.  The  identification  number  of  the  types  of 
equipment  required  for  team  operation — up  to  8 different 
types  allowed. 

b.  NO-ITEMS.  The  quantity  of  equipment  required  for  each 
equipment  type. 

6.  SUPPLY-SET 

a.  SUPPLY-NO-8.  The  identification  number  of  the  types  of 
supplies  required  for  team  operation — up  to  6 different 
types  of  supplies  allowed. 

b.  SUPPLY-CAP.  The  capacity  of  the  supply  item. 

c.  SUP-RATE.  The  consumption  rate  for  the  respective  supply 
item. 

7.  SERVICE.  The  service  Identification  number  to  which  the-  team 

belongs  (there  are  ten  seir/ice  types): 

a.  Headquarters 

b.  Welfare 

c.  Medical 

d.  Fire 
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Team  Table  continued. 


e.  Police 

f.  Rescue 

g.  Engineering 

h.  Transportation 
1.  Communication 
j . Stock  Control 

8.  TEAM-NAME.  The  name  of  the  respective  team. 

9.  MOB-CODE.  The  code  which  indicates  whether  a vehicle  is  needed 
in  order  for  the  team  to  operate. 

a.  1 indicates  that  a vehicle  is  needed. 

b.  0 indicates  that  no  vehicle  is  required. 


2. 


Alternative  Table 


The  format  for  the  alternative  table  Is  given  in  Table  A-II, 
TABLE-C  FORMAT. 


Table  A-Il 
TABLE-C  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Card 

Columns 

Remarks 

ALTN-TABLE* 

Occurs  6 times . 

PROB-CLASS 

PRDB-CODE 

X 

PROB-SER 

99 

SO-PROB 

99 

PROB-NO 

XX 

Occurs  9 times . 

NO-ALTN 

9 

OPN-PAIR 

Occurs  7 times. 

BASE 

999 

COMP 

999 

FILLER 

X 

Occurs  7 times. 

FILLER 

X(7) 

Format  for  each  of  the  four  alternative  problem  types  (i.e. , Control-C, 
Damage-D,  Increase  Readiness-l,  and  Relief-R)  are  Identical;  therefore, 
only  a general  explanation  is  given. 

1.  PROB-CLASS 

a.  PRDB-a)DE.  The  identification  code  for  the  problem  type. 

b.  PBOB-SER.  Sequence  number  in  the  alternative  table. 

2.  NO-PROB.  The  problem  set  number. 

3.  PROB-MO.  The  number  of  each  problem  in  the  set. 

4.  NO-ALTN.  The  nianber  of  alternatives  in  the  problem  set. 

5.  OPN-PAIR.  Operation  number  pair. 

a.  BASE.  Oparation  number  to  be  performed  at  the  current  location. 

b.  COMP.  Operation  nuaber  to  be  performed  at  the  other  location. 
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3.  Work  Table 

The  fonnet  for  Che  work  table  which  Is  associated  with  the  func- 
tions is  given  in  Table  A-III,  WORK-TABLE  FORMAT.  A brief  description  of 
each  variable  is  given  below. 

Table  A-III 


WORK-TABLE  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Remarks 

WORK-TAB 

WORK 

FILLER 

WK-NO 
PREP-RATE 
PROD- RATE 
WK-CAPACm 
FILLER 

X 

99 

999V999 

999V999 

9(6) 

X(59) 

Occurs  42  times. 

1.  WK-NO.  The  function  Identification  number. 

2.  PREP-RATE.  The  time  spent  in  preparation  per  unit  Co  be 
processed. 

3.  PROD-RATE.  Hours  per  unit  processed. 

A.  WK-CAPACITY.  Maximum  number  of  units  Chat  can  be  processed  by 
a given  team. 


1 ; 


rw 

4^ 
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4. 


Function  Table 


r 


The  format  for  this  table  is  given  in  Table  A- IV,  F-TABLE  FORMAT. 

Table  A-IV 
F-TABLE  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Card 

Co  Ilians 

Remarks 

FUNCTION-TABLE 

Occurs  42  times,  one  card 

for  each  function,  plus  1 

extra  set  (for  storage 

space) . 

FUNCTION-NO 

99 

1-2 

FUNCTION-NAME 

X(12) 

3-14 

NO-ALTN 

9 

15 

ALTN-TEAM 

16-42 

Occurs  3 times. 

TEAM-NO 

99 

(16-17)  } 

EFF-7 

9V99 

(18-20)  S 

First  alternate  team. 

TRAIN-HRS 

999V9 

(21-24)  ) 

(25-26)  ) 

(27-29)  ) 

Second  alternate  team. 

(30-33)  ) 

(34-35)  ) 

(36-38)  > 

Third  alternate  team. 

(39-42)  ) 

ALLOW 

99 

43-62 

Occurs  10  times. 

(43-44) 

First 

(61-62) 

Tenth 

1.  FUNCTION-NO.  The  identification  number  of  the  function. 

2.  FUNCTION-NAME.  The  name  of  the  function. 

3.  NO-ALTN.  The  number  of  teams  that  can  perform  this  function. 

4.  ALTN-TEAM 

a.  TEAM-NO.  Team  identification  numbei; 

b.  EFF-7.  The  efficiency  with  which  the  team  can  perform  the 
function. 

c.  TRAIN-HRS.  The  average  hours  a team  must  spend  in  training. 

5.  ALLOW.  Specified  whether  this  function  is  allowed  or  disallowed 
under  the  conditions  specified  by  the  ten  possible  environmental 
conditions  determined  by  the  environment  class. 

a.  0 indicates  disallowed. 

b.  1 indicates  allowed. 


D-8 


I 


tl 

H 

II 


FORMAT. 


Operations  Table 

The  format  for  the  Operations  Table  Is  shown  In  Table  A-V,  TABLE-0 


Table  A-V 
TABLE-0  FORMAT 


COBOL 

Variable 


OPN-TABLE 


OPN-NO 

OPN-NO-T 

NO-FUNC 

OP-FUNC-SET 

FUNC-NO 


COBOL 

Format 


Card 

Columns 


6-29 

(6-7) 

(8-9) 


Remarks 


Occurs  144  times — one  card 
for  each  operation 


Occurs  12  times. 


FILLER 

OPN-ALTN 

OPN-A 

OPN-B 

COMBINATION-TABLE 

NUM-COMB 

OPN-COMB 

OPN-COMP 

COMB-NO 


FILLER 


(28-29) 

30 

31-33 

34-36 

37 

38-79 

(38-40) 

(41-43) 


(74-76^ 

(77-79) 

80 


Occurs  7 times. 
First 


Seventh 


OPN-NO.  The  Identification  number  of  the  operation. 

NO-FUNC.  The  number  of  functions  In  operation. 

OP-FUNC-SET.  Function  number  for  each  function  in  operation. 
OPN-ALTN.  Operation  pair  equivalent  of  OPN-NO  above. 

a.  OPN-A.  Initial  part  of  operation. 

b.  OPN-B.  Complementary  part  of  operation. 

COMBINATION-TABLE 

a.  NUM-COMB.  The  number  of  combinations  for  a given  operation. 

b.  OPN-COMB 

(1)  0PN-(X)MF.  The  initial  operation  for  the  combination 
number. 

(2)  COMB-NO.  The  Identification  number  for  the  combination 


6.  Land-Use  Class  Density  Table 

The  format  for  the  LUC  Density  Table  is  given  in  Table  A-VI, 
TABLE- 2 FORMAT. 


Table  A-VI 
TABLE-2  FORMAT 


f 

COBOL 

Variables 

COBOL 

Format 

Card 

Columns 

Remarks 

TAB-2 

FILLER 

X 

1 

Occurs  64  times,  one  card 
for  each  land-use  class. 

TYPE-STRUC 

9999 

2-5 

DENSITY-A 

9999V99 

6-11 

FILLER 

X(69) 

12-80 

1.  TYPE-STRUC.  Identification  number  for  the  types  of  land  use 

2.  DENSITY-A.  The  average  number  of  buildings  (all  structure  types) 
per  square  mile  for  the  particular  land  use. 
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Master  Status  File 


This  section  contains  a detailed  description  of  the  input  data  and 
its  format  in  the  Master  Status  File  (MSF) . This  file  is  used  by  both 
TELOS  and  LEMOS  and  thus  forms  the  main  link  between  the  systems. 

1.  AREA-RECORD  Record 

The  format  for  the  record  is  shown  in  Table  B-I,  AREA-RECORD 
FORMAT.  One  card  is  needed  for  each  unit  area. 

Table  B-I 

AREA-RECORD  FORMAT 


COBOL  VariaLle 

COBOL 

Format 

Card 

Columns 

Remarks 

CODE-1 

9 

1 

Value  is  1. 

FILLER 

X 

2 

TIME-PERIOD 

9999 

! 3-  6 

Sequence  number  of  time  period 

FILLER 

X(5) 

7-11 

ZONE-PART 

999 

12-14 

Zone  number 

AREA- PART 

999 

15-17 

Area  number 

FILLER 

XX 

18-19 

T-INTERVAL 

9(5) 

20-24 

In  minutes 

LAT 

99V999  1 

25-29 

Latitude 

LON 

999V999  ’ 

30-35 

Longitude 

TOTAL-AREA 

9999V99 

36-41 

LL’C-PCT 

X(20) 

42-61 

99  occurs  10  times 

cm- DOSE- RATE 

9(5) 

62-66 

r/hr. 

BLAST- RISK-CODE 

9 

67 

FALLOUT-RISK-CODE 

9 

68 

AREA-POP 

9(6) 

69-74 

SHELTER 

9(6) 

75-80 

CES- STATUS-CODE 

9 

81 

FILLER 

X(7) 

82-88 

a.  CODE-1.  A "1". 

b.  TIME-PERIOD.  The  sequence  number  of  the  current  time 
period. 

c.  ZONE-PART.  The  zone  in  which  the  unit  area  is  located. 

d.  AREA- PART.  The  unit  area  sequence  number. 

e.  T-INTERVAL.  The  length  of  the  current  time  interval. 

f.  LAT.  The  latitude  (weighted  by  area)  of  the  centroid  of 
the  unit  area,  to  0.001  degree. 

g.  LON.  The  longitude  (weighted  by  area)  of  the  centroid  of 
the  unit  area,  to  0.001  degree. 
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AREA-RECORD  Record,  continued. 


h.  TOTAL-AREA.  The  area  of  the  unit  area,  In  square  miles. 

i.  LUC-PCT.  The  percentages  of  area  distribution  (the  actual 
assigned  area,  see  Section  V)  of  Land-Use  Classes  (LUC)  R1 
Vacant,  R2,  RM,  Lakes  and  Water,  Commercial  (general). 
Commercial  (major).  Industrial,  Agricultural,  and  the  re- 
maining LUC's,  respectively. 

j.  CUR- DOSE- RATE.  The  dose  rate  for  the  current  time  period. 

In  Roentgens /hour. 

k.  BLAST- RISK-CODE.  A single  digit  code  expressing  the  overall 
vulnerability  of  the  unit  area  with  respect  to  blast: 

(0)  Don’ t know 

(1)  No  blast  risk 

(2)  Low  blast  risk 

(3)  High  blast  risk. 

l.  FALLOUT-RISK-CODE.  A single  digit  code  expressing  the  over- 
all vulnerability  of  the  unit  area  with  respect  to  fallout: 

(0)  Don' t know 

(1)  No  fallout  risk 

(2)  Low  fallout  risk 

(3)  High  fallout  risk. 

m.  AREA-POP.  The  total  population  of  the  unit  area. 

n.  SHELTER.  The  total  number  of  shelter  spaces  In  the  unit 
area. 

o.  GEN- STATUS- CODE.  A single  digit  code  expressing  the  overall 
status  of  the  unit  area: 

(1)  Original  state 

2 

(2)  Unscathed  (<1  psl  and  <4  cal/cm  ) 

2 

(3)  Scathed  (1-2  psl  and  <4  cal/cm  ) 

2 

(4)  Stricken  (2-20  psl  or  >4  cal/cm  ) 

2 

(5)  Devastated  (>20  psl  and  >4  cal/cm  ). 
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2.  STKUC-DATA  Record 

The  format  for  the  record  is  shown  In  Table  B-II,  STRUC-DATA 
FORMAT.  One  card  la  needed  for  each  building  type  (Cols.  20-22)  In  each 
land  use  class  present  In  the  unit  area. 

Table  B-II 


STRUC-DATA  FORMAT 


COBOL  Variable 

COBOL 

Format 

Card 

Columns 

Remarks 

CODE-2 

9 

Value  2 

FILLER 

X 

TIME-PERIOD 

9999 

Sequence  number  of  time  period 

FILLER 

X(5) 

7-11 

ZONE-PART 

999 

12-14 

Zone  number 

AREA-PART 

999 

15-17 

Area  number 

LUC 

99 

18-19 

See  Table  C-I,  "LAND-USE-CODES" 

STORIES-CODE 

9 

20 

BLAST-RESIST-CODE 

9 

21 

FIRE-RESIST-CODE 

9 

22 

DAMAGE-CODE 

99 

23-24 

GEN-DEBRIS 

9 

25 

ROUTE-DEBRIS 

9 

26 

NO- UNDAM 

9(6) 

27-32 

.NO- STAGE  1 

9(6) 

33-38 

NO- STAGE 2 

9(6) 

39-44  . 

SO-STAGE3 

9(6) 

45-50 

n6-STAGE4 

9(6) 

51-56 

AREA-AFLAME 

99 

57-58 

nLLER 

X(30) 

59-88 

a.  CODE-2.  A "2", 

b.  TIME-PERIOD.  The  sequence  number  of  the  current  time  period. 

c.  ZONE-PART.  The  zone  in  which  the  unit  area  Is  located. 

d.  AREA-PART.  The  unit  area  sequence  number. 

e.  LUC.  The  Identification  number  for  the  land-use  code 
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STRUC-DATA  Record,  continued 


f.  STORIES-CODE.  A code  which  gives  the  number  of  stories  of 
the  facility  being  described: 


(0)  Underground 

(1)  1-2  stories 

(2)  3-5  stories 

(3)  6-10  stories 

(4)  11  - 15  stories 

(5)  16  - 20  stories 

(6)  21  - 25  stories 

(7)  26  - 30  stories 

(8)  31  - 40  stories 

(9)  Over  40  stories 


g- 


h. 


BLAST-RESIST-CODE.  A code  which  gives  the  blast  resistance 


of  the  facility: 

(0)  Special 

(1)  Light  panel  or  framing 

(2)  Masonry  bearing  wall 

(3)  Column  and  beam,  curtain  walls 

(4)  Column  and  beam,  In-fll  walls 

(5)  Column  and  slab,  curtain  walls 

(6)  Column  and  slab,  in-fll  walls 

(7)  Column  and  plate,  curtain  walls 

(8)  Column  and  plate,  In-fil  walls 

(9)  Long-span  construction 

FI RE- RESIST-CODE.  A code  which  gives 
of  the  facility: 


(0) 

(1) 

Special 

A wall  A 

roof 

L 

combustible 

load 

(2) 

A wall 

A 

roof 

M 

combustible 

load 

(3) 

A wall 

A 

roof 

H 

combust lb el 

load 

(4) 

A wall 

B 

roof 

L 

combustible 

load 

(5) 

A wall 

B 

roof 

M 

combustible 

load 

(6) 

A wall 

B 

roof 

H 

combustible 

load 

(7) 

B wall 

B 

roof 

L 

combustible 

load 

(8) 

B wall 

B 

roof 

M 

combustible 

load 

(9) 

B wall 

B 

roof 

H 

combustible 

load 

Where  A wall  has  minor  susceptibility 
A roof  has  minor  susceptibility 
B wall  has  major  susceptibility 
B roof  has  major  susceptibility 
L load  is  less  than  20  Ibs/ft^ 

M load  is  20  to  40  Ibs/ft^ 

H load  is  over  40  Ibs/ft^ 


the  fire  resistance 


to  fire  spread 
to  fire  spread 
to  fire  spread 
to  fire  spread 
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STRUC-DATA  Record,  continued. 


k.  ROUTE-DEBRIS.  A code  which  Is  used  primarily  for  LUC  05  to 
describe  the  overall  debris  In  streets.  (See  j.  GEN-DEBRIS, 
above . ) 

l.  NO-UNDAM.  The  number  of  structures  of  the  given  type  un- 
damaged or  not  burned  out. 

m.  NO-STAGEl.  The  number  of  structures  of  the  given  type  that 
are  In  stage  1 (Ignited). 

n.  NO-STAGE2.  The  number  of  structures  of  the  given  type  that 
are  In  stage  2 (growing  Intensity) . 

o.  NO-STAGE3.  The  number  of  structures  of  the  given  type  that 
are  In  stage  3 (past  peak) . 

p.  NO-STAGE4.  The  number  of  structures  of  the  given  type  that 
are  In  stage  4 (burned  out) . 

q.  AREA-AFLAME.  The  percent  of  the  area  In  the  LUC  that  Is 
aflame. 

I.  DAMAGE-CODE.  A code  which  gives  the  damage  suffered  by  the 
facility: 

00  Undamaged 

10  Light  blast  damage 

11  Heavy  blast  damage 

12  Light  blast  and  light  fire  damage 

20  Light  fire  damage 

22  Heavy  fire  damage 

91  Destroyed  by  blast  only 

92  Destroyed  by  fire  only 

93  Damaged  by  blast  destroyed  by  fire 

94  Destroyed  by  blast  and  fire  multiple  weapon 

J.  GEN-DEBRIS.  A code  which  is  used  for  all  LUC's  other  than  05 
to  describe  the  overall  debris  in  the  land-use-class: 

(0)  No  debris 

(1)  Scattered 

(2)  Light  debris 

(3)  Medium  debris 

(4)  Heavy  debris 


(5)  Extra  heavy  debris 


! 


3.  SHELTER-DATA  Record 

The  format  for  the  record  is  shown  In  Table  B-III,  SHELTER-DATA 

FORMAT. 

Table  B-III 
SHELTER-DATA  FORMAT 


COBOL  Variable 

COBOL 

Format 

Card 

Columns 

Remarks 

CODE- 3 

9 

1 

Value  3 

SUBTYPE- CODE 

9 

2 

Value  0*  spaces;  value  1 ■ people 

TIME- PERIOD 

9999 

3-  6 

Sequence  number  of  time  period 

FILLER 

X(5) 

7-11 

ZONE-PART 

999 

12-14 

Zone  number 

AREA-PART 

999 

15-17 

Area  number 

LUC 

99 

18-19 

STORIES-CODE 

9 

20 

1 

BLAST-RESIST-CODE 

9 

21 

/ Same  as  STRUC-DATA  Record 

FIRE-RESIST-CODE 

9 

22 

) 

TOTAL- SPACES 

9(8) 

23-30 

(Or  people  if  SUBTYPE-CODE  - 1) 

BELOW-PF-DIST 

X(16) 

31-46 

V99  occurs  8 times 

LOWER-PF-DIST 

X(16) 

47-62 

V99  occurs  8 times 

UPPER-PF-DIST 

X(16) 

63-78 

V99  occurs  8 times 

FILLER 

X(10)  , 

79-88 

sr  ' 


a.  CODE- 3.  A "3". 

b.  SUBTYPE-CODE.  A value  of  "0"  indicates  shelter  spaces,  and 
a value  of  "1"  Indicates  people  In  shelter  spaces. 

c.  TIME-PERIOD.  The  sequence  number  of  the  current  time  period. 

d.  ZONE-PART.  The  zone  In  which  Che  unit  area  is  located. 

e.  AREA- PART.  The  unit  area  sequence  number. 

f.  LUC. 

g.  STORIES-CODE.  See  STRUC-DATA  Record. 

h.  BLAST-RESIST-CODE.  See  STRUC-DATA  Record. 

I.  FIRE-RESIST-CODE.  See  STRUC-DATA  Record. 

J.  TOTAL-SPACES.  The  total  number  of  spaces  or  people  In 
■paces  in  structures  of  the  given  type. 
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SHELTER-DATA  Record,  continued. 


k.  BELOW-PF-DIST.  The  distribution  of  shelter  spaces  (or 
people  In  spaces)  by  PF  category  for  below-ground  spaces: 


(1) 

NFSS 

B 

PF: 

<5 

(2) 

NFSS 

A 

PF: 

5-9 

(3) 

NFSS 

0 

PF: 

10-19 

(4) 

NFSS 

1 

PF: 

20-39 

(5) 

NFSS 

2 

PF: 

40-69 

(6) 

NFSS 

3 

PF: 

70-99 

(7) 

NFSS 

4 

PF: 

100-149 

(8) 

NFSS 

5-6 

PF: 

150-499 

(9) 

NFSS 

7-8 

PF: 

500-up 

l.  LOWER-PF-DIST.  The  distribution  of  shelter  spaces  (or 
people  in  spaces)  by  PF  category  for  lower  story  spaces 
(see  above  for  codes). 

m.  UPPER-PF-DIST . The  distribution  of  shelter  spaces  (or 
people  in  spaces)  by  PF  category  for  upper  story  spaces 
(see  above  for  codes). 
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PERSONNEL-STATUS  Record 


The  format  for  Che  record  Is  shown  In  Table  B-IV,  PERSONNEL- 


STATUS  FORMAT. 


Table  B-IV 


(fw  I 

■V 


PERSONNEL-STATUS  RECORD 


COBOL  Variable 

COBOL 

Format 

Card 

Columns 

Remarks 

CODE- 4 

9 

1 

Value  4 

FILLER 

X 

2 

TIME-PERIOD 

9999 

3-  6 

Sequence  number  of  time  period 

FILLER 

X(5) 

7-11 

ZONE-PART 

999 

12-14 

Zone  number 

AREA- PART 

999 

15-17 

Area  number 

LUC 

99 

18-19 

STORIES-CODE 

9 

-20 

) 

BLAST-RESIST-CODE 

9 

21 

> Same  as  STRUC-DATA  Record 

FIRE-RESIST-CODE 

9 

22 

) 

INJURY-CODE 

99 

23-24 

TRAPPED  1 

9(6) 

25-30 

UNINJ  j 

9(6) 

31-36 

Those  who  originally  had  INJURY-CODE 

INJ-PHASES:  1 

X(39) 

37-75 

1 

MEAN-TIME 

MIN-TIME 

MAX-TIME 

CASUALTIES 

99V9 

99 

99 

9(6) 

37-49 

50-62 

63-75 

X(13)  occurs  3 times 

MEAN-DOSE 

999V9  ' 

76-79 

MIN-DOSE 

999 

80-82 

MAX-DOSE 

999 

83-85 

nLLER 

XXX 

86-88 

a.  CODE-4.  A "4". 


b.  TIME-PERIOD.  The  sequence  number  of  the  current  time  period. 

c.  ZONE-PART.  The  zone  in  which  Che  unit  area  is  located. 

d.  AREA-PART.  The  unit  area  sequence  number. 

e.  LUC. 

f.  STORIES-CODE.  See  STRUC-DATA  Record. 

g.  BLAST-RESIST-CODE.  See  STRUC-DATA  Record. 

h.  HRE-RESIST-CODE.  See  STRUC-DATA  Record. 

1.  INJURY-CODE.  A code  which  gives  the  type  of  Injury: 

00  Uninjured 

10  Blast 

11  Multiple  blast 

20  Thermal 

21  Multiple  thermal 

22  Blast  and  thermal 

30  Radiation 


D-18 


.1 


) 


PERSONNEL-STATUS  Record,  continued. 

31  Multiple  radiation 

32  Blast  and  radiation 

33  Thermal  and  radiation 

40  Fire  Injuries 

41  Multiple  fire 

42  Blast  and  fire 

43  Thermal  and  fire 

44  Radiation  and  fire 

50  Fallout  Injuries 

90  Fatalities 

91  Blast  killed  Immediately 

92  Thermal  or  fire  killed  Immediately 

93  Radiation  killed  Immediately 

94  Combination  (91,92,93)  killed  Immediately 

95  Died  from  blast  Injury 

96  Died  from  thermal  or  fire  Injuries 

97  Died  from  radiation  Injury 

98  Died  from  combination  of  effects 

99  All  causes 

J.  TRAPPED.  The  number  of  people  (Including  CD)  with  the  given 
injury  code  and  building  type  who  are  trapped. 

k.  UNINJ.  The  number  of  people  (including  CD)  who  either  origi- 
nally had  the  given  injury  code  and  are  now  healthy  or  were 
never  Injured. 

l.  INJ-PHASES.  The  Injured  people  (Including  CD)  are  subdivided 
Into  three  groups  (phases)  depending  upon  their  time  of 
injury.  The  following  variables  occur  in  three  sets,  corres- 
ponding to  the  three  phases: 

(1)  MEAN-TIME.  The  mean  time  at  which  people  in  the  given 


phase  were  Injured. 

(2)  MIN-TIME.  The  earliest  time  at  which  people  In  the 
given  phase  were  Injured. 

(3)  MAX-TIME.  The  latest  time  at  which  people  In  the 


given  phase  were  injured. 

(4)  CASUALTIES.  The  number  of  people  (Including  CD)  In 
the  given  phase  with  the  given  Injury  code. 

m.  MEAN-DOSE.  The  average  accumulated  dose  (in  rads)  for  all 
people  Included  on  the  record  as  of  the  beginning  of  the 
current  period. 

n.  MIN-DOSE.  The  minimum  dose  (In  rads)  accumulated  by  the 
beginning  of  the  current  period. 

o.  MAX-DOSE.  The  maximum  dose  (In  rads)  accumulated  by  the 
beginning  of  the  current  period. 
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5.  SPECIAL-RESOURCES  Record 

The  format  for  the  record  Is  shown  In  Table  B-V,  SPECIAL-RESOURCES 
FORMAT.  All  CD  resources  are  described  using  this  format. 

Table  B-V 

SPECIAL-RESOURCES  FORMAT 


COBOL  Variable 


CODE- 5 

SUBTYPE-CODE 

TIME-PERIOD 

FILLER 

ZONE-PART 

AREA-PART 

LUC 

FILLER 

ASSET-CODE 

ASSET-NUMBER 

POSTURE 

SUPV-COMP 

SUPV-ORGN 

CONDITION 

EFF-FACTOR 

QUANTITY 

TRAILERS; 

(Facilities) 

IFAC-DAM-CODE 
FAC-STAT-PCT 
FAC-DEBRIS 
FILLER 

(Shelter  Spaces) 

iSHEL-LVL-CODE 
PF-DIST 
FILLER 
(Personnel) 
INJ-CODE 
TRAPPED-PCT 
INJ-PHASES; 
MEAN-TIME 
MIN-TIME 
MAX-TIME 
INJ-PERC 
MEAN-DOSE 
MIN- DOSE 
MAX-DOSE 


COBOL 

Format 

Card 

Columns 

9 

1 

9 

2 

9999 

3-  6 

X(5) 

7-11 

999 

12-14 

999 

15-17 

99 

18-19 

XXX 

20-22 

9 

23 

99 

24-25 

99 

26-27 

9 

28 

9(8) 

29-36 

9 

37 

9V99 

38-40 

9(6) 

41-46 

X(30) 

47-88 

1 99 

j 47-48 

)X(25) 

49-73 

9 

74 

1 X(14) 

1 75-88 

( 

{ X(16) 

<48-65 

(X(23) 

(66-88 

99 

47-48 

9V99 

49-51 

X(30) 

52-81 

99V9 

99 

99 

9V99 

99V9 

82-84 

99 

85-86 

99 

86-87 

Value  5 

Value  0 ■ non- transient;  value  1 ■ transient 
Sequence  number  of  time  period 

Zone  number 
Area  number 


Value  1*  Non-CD;  value  2 ■ CD 
Not  used 


Only  for  Asset  Codes  1,  2,  or  3 


9V9999  occurs  5 times 


99  occurs  9 times 


X(10)  occurs  3 times  (once  for 
each  phase) 


In  tens  of  rads 


0-20 


r 


I 

I 

I 

I 


I 


I 

I 

I 

I 

1 

r 

I 
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I 

I 

I 
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SPECIAL-RESOURCES  Record,  conulnued. 

a.  CODE-5.  A "5". 

b.  SUBTYPE-CODE.  A value  of  "0"  indicates  non-transient  resources; 
a value  of  "1"  indicates  transient  resources. 

c.  TIME-PERIOD.  The  sequence  number  of  the  current  time  period. 

d.  ZONE-PART.  The  zone  in  which  the  unit  area  is  located. 

e.  AREA-PART.  The  unit  area  sequence  number. 

f.  LUC. 

g.  ASSET-CODE.  A single  digit  describing  the  asset  being 
described  on  the  record: 

(1)  Facilities 

(2)  Shelter  spaces 

(3)  People 

(4)  Equipment 

(5)  Material 

(6)  Supplies 

(7)  Teams 

h.  ASSET-NUMBER.  A double-digit  code  further  defining  the 
asset  listed  on  the  record. 

(1)  People 

(2)  Teams 

(3)  Spaces 

(4)  Building 

(5)  Equipment 

(6)  Rations 

(7)  Water 

(8)  Fuel 

(9)  Miscellaneous  supplies 

(10)  Material 

(11)  Capacity  units  (e.g. , beds,  hospitals) 

i.  POSTURE.  A double-digit  code  expressing  the  posture  of  the 
population: 

10  Inside  basement  prone 

11  Inside  basement  standing 

12  Inside  lower  floors  prone 

13  Inside  lower  floors  standing 

14  Inside  upper  floors  prone 

15  Inside  upper  floors  standing 

20  Outside  shielded  prone 

21  Outside  shielded  standing 

22  Outside  unshielded  prone 

23  Outside  unshielded  standing 
31  Trapped  in  basements 

J.  SUPV-COMP.  A single-digit  code  expressing  whither  or  not 

the  resources  listed  are  non-CD  (value > 1)  or  CD  (value  "CD). 


} 

I 

? 

t 
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SPECIAL-RESOURCES  Record,  continued. 


k.  SUPV-ORGN.  Not  used. 

l.  CONDITION.  A single-digit  code  expressing  the  condition  of 
the  resources,  used  in  conjunction  with  EFF-FACTOR  (see  below) : 

(0)  Undamaged  i 

(1)  Damaged  (repairable) 

(2)  Destroyed  (salvageable) 

(3)  Destroyed  (not  salvageable) 

m.  EFF-FACTOR.  A factor  which  expresses  what  percent  of  the 

resource  can  be  repaired  (if  CONDITION  * 1)  or  can  be  con- 
verted to  supplies  (if  CONDITION  ■ 2) . | 

n.  QUANTITY.  The  amount  of  the  resource  listed. 

TRAILERS:  Records  which  list  facilities,  shelter  spaces,  or  personnel  ‘ 

have  additional  data,  described  below.  *'> 

o.  FACILITIES  I 

(1)  FAC-DAM-CODE.  A double-digit  code  expressing  the  dam- 
age to  the  facilities  listed  (see  B-H.2.i  for  the  codes). 

(2)  FAC-STAT-PCT.  The  distribution  of  the  facilities  listed 
among  the  categories:  (1)  undamaged  or  burned  out; 

(ii)  burning,  stage  1;  (iii)  burning,  stage  2;  (iv)  burn- 
ing, stage  3;  (v)  burning,  stage  4. 

(3)  FAC-DEBRIS.  A single-digit  code  expressing  the  average  : 

amount  of  debris  in  the  facilities  listed  (see  B-H.2.J  ..3 

for  the  codes). 

p.  SHELTER  SPACES  | 

(1)  SHEL-LVL-CODE.  A single-digit  code  expressing  whether 

shelter  spaces  listed  are  below  ground  (value « 1) , | 

lower  stories  (value  ■ 2) , or  upper  stories  (value  « 3) . 

(2)  PF-DIST.  The  distribution  of  the  shelter  spaces  listed  j 

by  PF  category  (see  B-H.3.k  for  the  categories).  ' 


q .  PERSONNEL 

(1)  INJ-CODE.  A double-digit  code  expressing  the  type  of 
injuries  suffered  by  the  personnel  listed  (see  B-I.4.i 
for  the  codes) . 

(2)  TRAPPED-PCT.  The  percentage  of  the  personnel  listed 
who  are  trapped  (multiplies  QUANTITY) . 
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SPECIAL-RESOURCES  Record,  continued. 


i 

I 

i 
V 

I 

^ (3)  INJ-PHASES.  The  injured  people  are  subdivided  into 

three  groups  (phases)  depending  upon  their  time  of 
injury.  The  following  variables  occur  in  three  sets, 
I corresponding  to  the  three  phases: 

(a)  MEAN-TIME.  The  mean  time  at  which  people  in  the 
[ given  phase  were  injured. 

* (b)  MIN-TIME.  The  earliest  time  at  which  people  in 

I the  given  phase  were  Injured. 

I (c)  MAX-TIME.  The  latest  time  at  which  people  in 

. the  given  phase  were  injured, 

j (d)  INJ-PERC.  The  percent  of  the  injured  people  in 

the  given  phase  (multiplies  QUANTITY) . 

I (4)  MEAN-DOSE.  The  average  accumulated  dose  (in  tens  of 

rads)  for  all  people  Included  on  the  record  as  of  the 
I beginning  of  the  current  period. 

(5)  MIN-DOSE.  The  stallest  accumulated  dose  (in  tens  of 

Irads)  for  all  people  included  on  the  record  as  of  the 

beginning  of  the  current  period. 

(6)  MAX-DOSE.  The  largest  accumulated  dose  (in  tens  of 
I rads)  for  all  people  Included  on  the  record  as  of  the 

beginning  of  the  current  period. 

I 


j 


c. 


Problem  File 


Four  general  classes  of  problems  are  encountered  In  this  file.  Each 

class  has  a different  format.  A brief  description  of  these  four  major  types 
of  problems  (l.e..  Control,  Increased  Readiness,  Damage,  and  Relief)  and 
their  formats  are  given  below.  Records  of  two  or  more  classes  exist  for 
each  land-use  entry  within  a unit  area.  Control  and  readiness  problems  are 
always  present. 

1.  PRQB-TYPE-l  Record 

Problems  that  relate  to  the  ability  to  identify,  locate,  direct, 
coordinate,  or  otherwise  control  the  civil  defense  system  are  Identi- 
fied as  control  problems.  One  example  is  the  inability  to  inform 
people  due  to  the  disruptions  of  communication  facilities.  The  format 
of  the  first  problem  type  is  shown  in  Table  C-I,  PROB-TYPE-1  FORMAT. 

Table  C-I 
PROB-TYPE-1  FORMAT 


COBOL 

Variable 

' COBOL 
Format 

1 

Remarks 

ZONE-1 

999 

AREA-1 

999 

LUC-1 

99 

OLD-NEW 

9 

Defines  old  or  new  record 

CLASS- 1 

9 

Defines  transient  or  non-transient 

resources 

PROB-CLASS 

9 

Code  is  "1" 

UN-INFO 

X 

UN-PRDB 

X 

Not  used,  will  be  needed  in 

UN-ENVIRON 

X 

communication  submodels. 

RE-PROB 

X 

UN-ASOl-RES 

TEAM-1 

9(6) 

SPACES 

9(6) 

CAP-UNITS-1  ! 

9(6) 

Definition  of  capacity  units  vary  from 

land  use  to  land  use. 

EQUIP-SETS-1 

! 9(6) 

RATIONS- 1 

1 9(6) 

WATER-1 

' 9(6) 

FUEL-1 

1 9(6) 

SUP-UNITS- 1 

1 9(6) 

Definition  of  supply  units  vary  from 

1 

! 

land  use  to  land  use. 

FILLER 

1 X(7) 

D-7A 
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PROB-TYPE-l  Record,  continued. 

a.  ZONE-1.  The  zone  In  which  the  unit  area  la  located. 

b.  AREA-1.  The  unit  area  In  which  problem  type-1  Is  located. 

c.  LUC-1.  The  Identification  number  designating  the  land-use 
class  of  the  unit  area. 

d.  OLD-NEW.  A code  equal  to  1 Indicates  old  and  2 Indicates  new. 

e.  CLASS-1.  A code  equal  to  0 Indicates  non-transient  and  2 

Indicates  transient. 

f.  PROB-CLASS.  Code  Is  1,  Indicating  a control  problem. 

g.  UN-INFO.  The  uniformed  public. 

h.  UN-PROB.  Undefined  problem. 

1.  UN-ENVIRON.  Unknown  environment. 

j.  RE-PROB.  Unresolved  problem. 

k.  UN-ASGN-RES.  Unasslgned  resources  In  the  respective  land-use  area. 

(1)  TEAM-1.  The  quantity  of  teams  unasslgned. 

(2)  SPACES-1.  The  quantity  of  shelter  spaces  unasslgned 

(3)  CAP-UNITS-1,  The  quantity  of  capacity  units  unasslgned. 

(4)  EQUIP-SETS-1.  The  quantity  of  equipment  sets  unasslgned. 

(5)  RATIONS-1.  The  quantity  of  rations  unasslgned. 

(6)  WATER-1.  The  amount  of  water  (gallons)  unasslgned. 

(7)  FUEL-1.  The  amount  of  heating  fuel  (gallons)  unasslgned. 

(8)  SUP-UNITS-1.  The  quantity  of  supply  units  unasslgned. 
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2.  PROB-TYPE-2  Record 

Problems  that  relate  to  the  vulnerability  of  people  In  a 
preattack  situation  or  to  personnel,  facilities,  and  equipment  by 
teams  are  readiness  problems.  The  type-2  problem  format  is  shown 
in  Table  C-II,  PROB-TYPE-2  FORMAT. 


Table  C-II 
PROB-TYPE-2  FORMAT 


a. 

b. 

c. 

d. 

c. 

f. 


COBOL 

Variable 


COBOL 

Format 


Remarks 


ZONE-1 
AREA-1 
LUC-1 
OLD-NEW 
CLASS-1 
PROB-CLASS 
IHOP-PERS 
INOP-EQPT 
INOP-VEH 
INOP-FAC 
INOP-SUP 
FAC-DAM 
EQPT-DAM 
SHORTAGE 
UNPRO-PEO 
EQPT-EFF-FACTORl 
FILLER 


^10) 


9 

9(6) 

9(6) 

9(6) 

9(6) 

9(6) 

9(6) 

9(6) 

9(6) 

9(6) 

9V99 

X(2) 


Same  as  1 


Code  is  2 


ZONE-1.  The  zone  in  which  the  unit  area  is  located. 
AREA-1.  The  unit  area  in  which  problem  type-2  is  located. 
LUC-1.  The  identification  number  designating  the  land-use 
class  of  the  unit  area. 

PROB-CLASS.  Code  is  "2",  which  indicates  an  increase 
readiness  problem. 

INOP-PERS.  The  personnel  shortage  which  causes  a team 
to  be  inoperative. 

INOP-EQPT.  The  equipment  shortage  which  causes  a team 
to  be  inoperative. 


J 

] 

J 


g.  INOP-VEH.  The  vehicle  shortage  which  causes  a team  to 
be  inoperative. 

F . , 


§ 
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PROB-TYPE-2  Record,  continued. 


h.  IMOP-FAC.  A facility  shortage  which  causes  a team  to 
be  inoperative. 

1.  INOP-SUP.  The  supply  shortage  which  causes  a team  to 
be  Inoperative. 

j.  FAC-DAM.  The  number  of  facilities  damaged  In  the  problem 
area. 

k.  EQPT-DAM.  The  number  of  equipments  damaged  In  the  problem 
area. 

l.  SHORTAGE.  The  number  of  teams  needed  but  are  not  available 
to  solve  this  type  of  problem. 

m.  UNPRO-PEO.  The  total  number  of  people  In  the  problem  area 
who  are  threantened,  but  no  shelter  Is  available  to  them. 

n.  EQPT-EFF-FACTOR.  The  efficiency  of  equipment  which  Is 
damaged  but  not  destroyed. 


3 


3.  PROB-TYPE-3  Record 

Damage  control  problems  unlike  other  problem  types  prevent  the 
loss  of  a resource  or  Its  utility  rather  than  Improving  an  already 
degraded  condition.  Examples  of  this  type  of  problem  include 
firefighting,  decontamination,  and  debris  clearing.  The  type-3 
problem  format  is  given  in  Table  C-III,  PROB-TYPE-3  FORMAT. 


Table  C-III 
PROB-TYPE-3  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Remarks 

ZONE-1 

AREA-1 

X(10) 

Same  as  1 

LUC-1 

OLD-NEW 

CLASS-1 

PROB-CLASS 

9 

Code  is  3 

PROB-SET-3 

99 

NO-FAC-DAM 

9(6) 

FAC-FIRE 

NO-IGN-3 

9V99 

NO- AFLAME  1-3 

9V99 

NO-AFLAME  2-3 

9V99 

NO-BUBNED-3 

9V99 

AREA  ASO) 

9999V99 

NO-FAC-RAD 

9(6) 

NO- FAC- 3 

9(6) 

FAC-DEBRIS 

999 

FAC-RAD 

9(5)V99 

.LINK-DEBRIS 

999 

LINK-JAM 

9 

CHG-IND 

X 

Ifiller 

x(6)  : 
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PROB-TYPE-3  Record,  continued. 


a.  ZONE-1.  The  zone  in  which  the  unit  area  la  located. 

b.  AREA-1.  The  unit  area  In  which  problem  type-3  is 
located. 

c.  LUC-1.  The  Identification  number  designating  the  land-use 

class  of  the  unit  area. 

d.  OLD-NEW. 

e.  CLASS-1. 

f.  PROB-CLASS.  Code  Is  "3",  which  indicates  a damage 
problem  In  the  unit  area. 

g.  PROB-SET-3. 

h.  NO-FAC-DAM.  The  number  of  facilities  damaged  In  the 
problem  area. 

1.  FAC-FIRE.  The  number  of  facilities  afire,  damaged,  or 
destroyed  In  the  problem  area. 

(1)  N0-lCa<-3.  The  number  of  facilities  that  are  Ignited. 

(2)  NO- AFLAME  1-3.  The  number  of  facilities  that  are 
burning  but  are  not  Ignited. 

(3)  NO-AFLAME  2-3.  The  number  of  facilities  that  are 
burning  past  peak  Intensity. 

(4)  NO-BURNED-3.  The  number  of  facilities  that  have 
been  damaged  or  destroyed  by  fire.  (The  fire  has 
been  extinguished  or  has  burned  out.) 

j.  AREA-ASGN.  Total  area  assigned. 

k.  NO-FAC-RAD.  The  number  of  facilities  with  the  radiation 
level  (FAC-RAD). 

l.  NO- FAC-3.  The  total  number  of  facilities  In  the  area. 

m.  FAC-DEBRIS.  The  debris  level. 

n.  FAC-RAD.  The  radiation  level. 

o.  LINK-DEBRIS.  THe  debris  level  on  streets. 

p.  LINK- JAM.  The  auad>er  of  links  not  passable  because  of 
traffic  Jams. 

q.  CHG-IND 
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PROB-TYPE-4  Record 


This  leading  class  of  problems,  which  relates  directly  to  the 
state  of  people,  consists  of  shelter,  rescue,  treatment,  and  rehabili- 
tation problems.  It  sets  the  standard  for  measuring  the  degree  to 
which  human  life  has  been  disrupted.  All  other  problem  groups  must 
relate  to  this  one  and  in  this  sense  are  subordinate  to  it.  The 
format  for  type—4  problem  is  given  in  Table  C-IV,  PROB  TYPE— 4 FORMAT. 


I 


Table  C-IV 


1 

. j 


PROB-TYPE-4  FORMAT 


COBOL 

Variable 

Format 

Remarks 

ZONE-1 

LUC-1 

OLD-NEW 

X(10) 

Same  as  1 

CLASS-1 

PROB-CLASS 

9 

Code  is  4 

PROB-SET 

99 

See  Appendix  C Table 

QTY-PEOPLE 

9(6) 

C-XIIl 

PHASE-CODE 

9 

CAS-TYPE 

V99 

Occurs  15  times 

MEAN-TIME-OF-INJ 

99V9 

TIME-OF-INJ  (MIN) 

99 

TIME-OF-INJ  (MAX) 

99 

MEAN  CAS-DOSE 

99V9 

CAS-DOSE  (MIN) 

999 

CAS-DOSE  (MAX) 

999 

CD-CAS-CODE 

a. 

b. 

c. 

d. 

e. 

f. 

8* 


ZONE-1.  The  zone  in  which  the  unit  area  is  located. 
AREA-1.  The  unit  area  in  which  problem  type-4  is 
located. 


LUC-1.  The  identification  number  designating  the 
land-use  class  of  the  unit  area. 


See  Table  B-I 


OLD-NEW 
CLASS- 1 

PROB-CLASS.  Code  is  "4",  which  indicates  there  is  a 
relief  problem  in  the  unit  area. 

PROB-SET.  The  identification  number  for  the  problem 


set  . 
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PROB-TTPE-4  Record,  continued. 


h.  QTY-PEOPLE.  The  number  of  people  in  the  problem  area. 

1.  The  phase  of  the  prognosis  - change  period  in  which  the 

injuries  listed  fall. 

j.  CAS- TYPE.  The  casualty  distribution  of  the  problem  area. 
There  are  three  levels  respectively  (moderate,  severe,  and 
mortal)  of  each  of  the  following;  blast,  thermal,  nuclear, 
fire,  and  fallout.  There  is  one  undefined  type. 

k.  MEAN-TIME-OF-INJ.  The  average  time  at  which  the 
injuries  listed  on  the  record  occurred. 

l.  TIME-OF-INJ  (MIN)  & TIME-OF-INJ  (MAX).  The  minimum 
and  maximum  times  at  which  injuries  listed  on  this 
record  occurred. 

m.  MEAN-CAS-DOSE.  The  average  dose  of  the  casualties 
listed  on  this  record. 

n.  CAS-DOSE  (MIN)  and  CAS-DOSE  (MAX).  The  minimum  and 
maximum  dosages  of  the  casualties  listed  on  this  record. 

o.  CD-CAS-CODE.  Code  which  distinguishes  between  civil 
defense  and  non-clvll  defense  population. 

(1)  non-civil  defense 

(2)  civil  defense 
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1.  PART-1 

ft.  ZOllE-ID-2.  Thft  xone  In  which  the  unit"  ftrea  is  located. 

b.  ARBA-ID-2.  An  identification  of  the  location  of  the 
resources. 

c.  LUC-CODE-2.  The  identification  number  designating  the 
land-use  class  of  the  unit  area. 

d.  CLASS-2.  A code  which  indicates  whether  the  supplies 
belong  to  this  LUC  or  are  transient: 

(1)  non- transient 

(2)  transient 
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Resource-File 

The  format  for  the  file  is  shown  in  Table  D-I,  RESOURCE  DATA  FORMAT. 


Table  D-I 


RESOURCE  DATA  FORMAT 


COBOL 

ariable 


PART-1 

ZONE- ID-2 
AREA- ID-2 
LUC-CODE-2 
FILLER 
CLASS-2 
ENVIR(W-CLASS 
PART- 2 

PART-2A 

BOS 

TOTAL- AREA-2 
NO-STRUC 
TOTAL-TOTAL 
CD- FORCE 
TOTAL-UNINJ 
RESOURCES 
RESOURCE 
REFUGEES 
PROB-CD 
PROB-NCD 
TOTAL-DEAD- 1 
CD-DEAD 
CD-POSTURE 
AVG-UNINJ-DOSE(NCD) 
AVG-UNIN J-DOSE (CD) 


9 

999V99 

9(6) 

9(6) 

9(6) 

9(6) 


Resource- File , continued. 

e.  ENVIRON-CLASS.  A code  denoting  the  set  of  fire,  radiation, 
and  debris  levels  existing  in  that  UA  (i.e. , equivalent 
to  BOS  designations  used  in  ALFA  NEOP) 

2.  PART-2 

a.  PART-2A 

(1)  BOS.  The  level  of  environment. 

(2)  TOTAL-AREA-2.  The  total  area  of  the  resource  location 
in  square  miles. 

b.  NO-STRUC.  The  number  of  structures  In  the  unit  area. 

c.  TOTAL-TOTAL.  The  total  number  of  people  in  the  unit  area. 

d.  a>-FORCE.  The  total  number  of  civil  defense  people  in  the 
unit  area. 

e.  TOTAL-UNINJ.  The  total  number  of  uninjured  people  In  the 
unit  area. 

f.  RESOURCES.  The  eight  resources  are  teams,  spaces,  capacity 
units,  equipment  sets,  rations,  water,  fuel,  and  supply  units. 

g.  REFUGEES.  The  number  of  refugees  from  other  unit  areas  to 
this  unit  area. 

h.  PROB-CD.  The  number  of  Injured  CD  people. 

1.  PROB-NCD.  The  number  of  Injured  non-CD  people. 

j.  TOTAL-DEAD-1.  The  total  number  of  dead  people. 

k.  CD-DEAD.  The  total  number  of  dead  CD  people. 

l.  CD-POSTURE.  The  level  of  protection  for  CD  personnel. 

(1)  Unwarned 

(2)  Warned 

(a)  Duck  for  cover 

(b)  Sheltered-fallout 

(c)  Sheltered-blast 

m.  AVG-UNINJ-DOSE(NCD)  and  AVG-ONINJ-DOSE(CD) . The  average 
dose  of  uninjured  people,  non-CD  and  CD,  respectively. 


D-1/ 

ALFA  HEOP,  EOC  Master  Check  List  (Zonal  Level).  Washington,  D.C. : 
Department  of  Defense,  Office  of  Civil  Defense,  FC  G-1.2/2,  April  1971. 
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E.  Organization  File 

The  foraat  for  the  file  Is  given  In  Table  E-I,  ORQl-RECORD  FORMAT. 


Table  E>I 
ORQt-RECORD  FORMAT 


COBOL 

COBOL 

Card 

Variable 

Format 

Columns 

Remarks 

FILLER 

X 

1 

ORGM-AREA 

9(3) 

2-4 

FILLER 

XX 

5-6 

OROi-DATA 

X(8) 

7-14 

Divided  into  four  parts: 

(7-8) 

Zone  number. 

(9-10) 

EOC  number. 

(11-12) 

Group  number. 

(13-14) 

Sector  niimber. 

ORGM-SERV 

99 

15-16 

1.  ORGN-AREA.  The  Identification  number  of  the  unit  area. 

2.  ORGN-DATA.  The  organization  nuTd>er  Is  divided  Into  four  parts 
(l.e..  Zone,  EOC,  Group,  and  Sector). 

3.  ORGN-SERV.  The  Identification  number  of  the  service  to  which  a 
team  belongs  (l.e.,  there  are  ten  types): 

a.  1 Indicates  headquarters. 

b.  2 Indicates  welfare. 

c.  3 Indicates  medical. 

d.  4 Indicates  fire. 

e.  S Indicates  police. 

f.  6 Indicates  rescue. 

g.  7 Indicates  engineering. 

h.  8 Indicates  transportation. 

1.  9 Indicates  communication, 

j.  10  Indicates  supply. 


. I 
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1.  ADDRESS-11 

a.  ORGN-11.  The  organization  number. 

(1)  ZONE-11.  Zone  identification  number. 

(2)  EOC-11.  EOC  identification  number. 

(3)  GROUP-11.  Group  identification  number. 

(4)  SECTOR-11.  Sector  identification  number. 

b.  SERVICE-11.  Service  identification  number.  (See  in 
this  appendix.  Section  E,  Organization  File,  part  3.) 

c.  AREA-ID-11.  Unit-area  identification  number. 

I 


COBOL 

Variable 

COBOL 

Format 

Remarks 

ADDRESS-11 

ORGN-11 

ZONE-11 

99 

EOC-11 

99 

GROUP-11 

99 

SECTOR-11 

99 

SERVICE-11 

99 

AREA-ID-11 

X(6) 

TEAM-ID-11 

99 

NO-TEAMS-11 

9(6) 

SECTOR-ENVIRON 

9 

Occurs  9 times. 

FILLER 

X(15) 

STATE-DISTRB 

PCT-BY-STATE 

V999 

Occurs  8 times. 

NO-FUNC-11 

99 

TEAMS-FORCE 

9(5)V9 

TEAMS-LOST 

9(5)V9 

i 

SUM- RES 

! 

RES-SUM 

9(6) 

Occurs  8 times.  ' 

! 

F.  Service  File 

The  format  for  the  file  is  shown  in  Table  F-I,  SERV-RECORD  FORMAT. 

Table  E“I 
SERV-RECORD  FORMAT 
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Service  File,  continued. 

2.  TEAM-ID-11  Team  type  identification  code. 

3.  NO-TEAMS-11  Number  of  teams  of  type  specified  above. 

4.  SECTOR-ENVIRON  BOS  numbers  encountered  in  each  sector. 

5.  STATE-DISTRB  Percent  of  teams  for  each  of  8 states. 

6.  NO-FUNC-11  Function  to  which  teams  are  currently  assigned. 

7.  TEAMS-FORCE  Total  teams  in  work  force. 

8.  TEAMS-LOST  Number  of  teams  deactivated. 


9 


SUM-RES 


Amount  of  resources  currently  assigned  to  work 
force. 
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Operations  File 

The  format  for  the  file  1*  shown  In  Table  G-I,  OPS-DATA  FORMAT. 

Table  G-I 
OPS-DATA  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Remarks 

ORGN-10 

X(8) 

ABEA-ID-10 

X(6) 

AREA-LINK-CODE 

OPS-ID-IO 

ID-OPS-IO 

X 

ORIGIN-IO 

X(6) 

OPS-LDC 

99 

SEQ-10 

99 

TYPE-10 

9 

CODE-10 

99 

ALT- 10 

9 

SEQ-lOA 

9 

ORIG-TIME 

999V9 

DC-CODE 

X 

PROBLEM-CODE 

99 

STATUS-10 

X 

OPS-QTY 

9(6) 

START-TIME-10 

999V9 

OPS-CODE 

999 

OPS-STATUS 

X 

COMP-OPS-CODE 

999 

COMP-STATUS 

X 

LIMIT-FUNC 

XX 

BEN-TYPE 

TOTAL- FUNC-SETl 

X 

OP-FUNC 

T0TAL-FUNC-SET2 

99 

Occurs  12  times. 

OP-FUNC2 

OPS-PRIORITY 

99 

Occurs  12  times. 

RANK-OPS 

OP8-N 

9 

OPS-1 

9V9999 

OPS-2 

9V9999 

OPS-3 

9V9999 

OPS-4 

9V9999 

FILLER 

X(ll) 

Operacions  File,  continued. 

1.  ORGN-10.  A field  that  designates  the  location  of  the  unit  area 
by  zone  number,  EOC  number,  group  number,  and  sector  number. 

2.  AREA-ID-10.  The  identification  number  of  the  unit  area. 

3.  AREA-LINK-CODE.  Identification  code  for  link  or  area  record. 

4.  OPS- ID-10 

a.  lD-OPS-10 

(1)  ORIGIN-10.  The  unit  area  in  which  the  problem  occurred. 

(2)  OPS-LOC.  The  land-use  class  in  which  the  problem  occurred. 

(3)  SEQ-10.  The  time  in  which  the  problem  occurred. 

(4)  TYPE-IO.  The  problem  type  (see  Section  C)  which  has 
occurred. 

(5)  CODE-10.  The  identification  of  the  problem  which  has 
occurred. 

b.  ALT-10.  The  alternative  solution  number. 

c.  SEQ-IOA.  Sequence  number  used  where  there  is  more  than  one  move 
made  in  solving  the  problem. 

5.  ORIG-TIME.  Undefined. 

6.  DC-CODE.  Undefined. 

7.  PROBLEM-CODE.  Undefined. 

8.  STATUS- 10.  Undefined. 

9.  OPS-QTY.  Designates  the  nunber  of  people,  structures,  or  other 
items  acted  upon  by  functions  being  performed  in  this  operation. 

10.  START-TIME-10.  Hour  in  which  the  initial  function  is  performed. 

11.  OPS-CODE.  Table  number  designating  the  set  of  functions  to  be 
performed  at  the  location. 

12.  OPS-STATUS.  The  code  which  designates  whether  the  operation 
has  been  completed  or  not. 

13.  COKP-OPS-CODE.  Table  nimd>er  designating  the  set  of  functions 
to  be  performed  at  some  other  location. 

14.  COMP-STATUS.  States  whether  the  above  function  has  been  completed 

or  not. 

15.  LIMIT-FUIIC.  The  identification  number  of  the  function  currently 
being  performed. 
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Operation  File,  continued. 

16.  BEN-TYFE.  Designates  the  type  of  benefit  (i.e.,  £urvivors, 
j^abor  potential  (health  level  of  survivors),  ^ob,  or  housing). 

17.  TOTAL-FUNC-SETl . Set  of  function  numbers  describing  the  operation. 

18.  T0TAL-FDNC-SET2.  Set  of  function  numbers  describing  the  comple- 
mentary operation. 

19 . OPS-PRIORITY 

a.  RANKS-OPS.  Code  designating  the  priority  given  to  the  four 

major  problem  types. 

b.  OPS-N 

(1)  OPS-1.  Numerical  value  of  the  priority  given  to 
survivors. 

(2)  OPS-2.  Numerical  value  of  the  priority  given  to 
the  labor  potential. 

(3)  OPS-3.  Numerical  value  of  the  priority  given  to 
Jobs. 

(4)  OPS-4.  Numerical  value  of  the  priority  given  to 
ho\islng. 


D-39 


H 


I 

1 

I 


Aaalgnawnt  File 

The  format  for  the  file  is  shown  in  the  Table  H-I,  ASGN-DATA  FORMAT. 


Table  H-I 

AS(ai>DATA  FORMAT 


COBOL 

VarUbl* 

COBOL 

Potaac 

Raaarka 

CDR-AORS 

CUK-OBE 

zx 

CUB-DA 

zx 

CCB-SA 

XX 

CVB-LDC 

99 

OUT-ADBS 

ZONE-A 

99 

lOC-A 

99 

, 

CBP-A 

99 

SEC-4 

99 

oni-4 

oni-4-i 

OllGlII-4 

X(6) 

LDC-4 

99 

SEQ-4 

99 

Tt?B-4 

9 

CODE-4 

99 

ALT-4 

9 

•• 

SIQ-4A 

9 

KEW-AOBS 

9 

TBAM-4 

99 

OBCN-4 

Bon 

99 

EOC 

99 

CBP  ' 

99 

SEC 

99 

SEBVICE-4 

99 

lES-ASCH 

9(0 

Occurs  8 tlats 

ASCK-On 

9(6) 

rUIIC-80-4 

99 

Tiia-tii-n.iic 

9(3)V9 

STAIX-TIME 

9(3)  V9 

ABUVAL-TIME 

9(3)  V9 

COIVLETlOS-TDa-UT 

9(3)V9 

OOMFLEtlOH-TIia-ACI 

9(3)V9 

THB-M 

9(3)  V9 

THB-t 

9(3)V9 

TIB-E 

9(3)V9 

TBB-0 

9(3)  V9 

FBEE-THB 

9(3)  V9 

PIDD-THB 

9(3)99 

BEB-CODE 

XX 

MO-POT-BEH 

9(6) 

W-4 

W999 

SP-4 

99999 

SP-41 

99999 

SP-42 

99999 

SP-43 

99999 

SP-U 

99999 

SO-ASCM 

999 

PP-4 

99 

AUA-ADBS2 

zon-Aou 

999 

ABtA-ADBS3  g 

999 

PXLLU 

X(26) 

ASCM-PBIOB-SIQ 

99 

PUXU 

X(S) 
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Assignment  File,  continued. 


1. 

CUR-AORS. 

Current  organization  identification  of  the  area  being 

processed. 

a . 

CUR-OBE 

. Current  OBE  number. 

b. 

CUR-UA. 

Current  unit  area  nunfcer. 

c . 

CUR-SA. 

Current  sector  number. 

d. 

CUR-LUC 

. Current  land-use  class  of  the  area. 

2. 

DEST- 

-AORS. 

Organization  to  which  the  destination  area  belongs. 

a . 

ZONE-4. 

Zone  number. 

b . 

EOC-4. 

EOC  number. 

c . 

GRP-4. 

Group  number. 

d. 

SEC-4. 

Sector  nuid>er. 

3. 

OPN-4 

a. 

OPN-4-1 

. Operation  number  to  which  the  function  belongs. 

(1)  ORIGIN-4.  ' 

(2)  LUC-4. 

(3)  SE(^4. 

(4)  TYPE-4.  See  Section  C,  Operations  File,  for 

/ definitions. 

(5)  CODE-4. 

b.  ALT-4. 

c.  SEQ-4A. 

NEU-ADRS.  Undefined. 

TEAM-4.  The  team  Identification  nunber  (see  Table  C-II). 

ORGN-4.  The  organization  to  which  the  team  is  currently 

assigned. 

a.  ZONE.  Zone  number. 

b.  EOC.  EOC  number. 

c.  GRP.  Group  nuadber. 

d*  SEC.  Sector  nunber. 

SERVICE-4.  IdentifiCAtion  number  of  the  service  to  which 

the  team  belongs.  (See  In  this  appendix.  Section  H,  Organlzatlor 

File,  part  3 for  a list  of  these  services.) 

RES-ASGN.  Set  of  resources  required  by  the  team  to  perform 
the  function. 

ASGN-QTT.  Quantity  of  people,  facilities,  or  other  resources 
being  affected  by  the  function. 
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Assignment  File,  continued. 

10.  FONC-NO-A.  Identification  number  of  the  function  to  be  performed 
by  the  team. 

11.  TIME-IN-FUNC.  The  total  hours  a function  has  been  performed. 

12.  STAKT-TIME.  The  time  at  which  the  function  was  begun. 

13.  AKRIVAL-TIME.  The  arrival  time  of  the  team  at  the  designated 
location  to  perform  the  function. 

14.  OOMPLETION'TIME-EST.  The  estimated  completion  time  of  the 
function. 

15.  COMPLETION-TIME-ACT.  The  actual  time  It  took  the  team  to 
complete  the  fvnctlon. 

16.  THR-M.  The  team  hours  consumed  In  movement. 

17.  THR-I.  The  time  spent  In  waiting  by  the  team  for  some  reason 
or  other  before  the  function  was  performed. 

18.  THR-R.  The  restricted  time  the  team  had  to  wait  before  they 
could  perform  the  function  (e.g.,  radiation  level  too  high). 

19.  THR-0.  The  time  spent  by  the  team  because  of  the  Inability 
to  operate  for  lack  of  personnel,  equipment,  etc. 

20.  PREP-THR.  The  time  spent  by  the  team  In  preparation  before 

performing  the  function. 

21.  PROD-THR.  The  production  time. 

22.  BEN-CODE.  The  benefit  code. 

23.  NO-POT-BEN.  The  number  of  benefits  that  will  be  derived. 

24.  IP-4.  Initial  priority  designation,  (l.e., 

NO-POT-BEN 

PREP-THR  + PROD-THR 

25.  SP-4.  Service  priorities  at  the  current  location. 

26.  SP-41.  Service  priorities  at  the  current  sector  level. 

27.  SP-42.  Service  priorities  at  the  current  group  level. 

28.  SP-43.  Service  priorities  at  the  current  EOC  level. 

29.  SP-44.  Service  priority  at  the  zone  level. 

30.  NO-ASGN.  The  number  of  teams  assigned. 

31.  FP-4.  Functional  Priority  — assigned  externally,  if  desired. 

32.  AREA-AORS2.  Designated  zone  and  unit  area. 

33.  ASGM-PRIOR-SEQ.  Preserves  the  priority  order  during  sorting 
routines. 
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Trip  File 

The  format  for  the  file  Is  shown  In  Table  I>I,  TRIP-DATA  FORMAT 


Table  I-I 
TRIP-DATA  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Remarks 

OPN-NO 

X(15) 

ID-OBGN 

FILLER 

3X 

ID-D-EOC 

93 

FILLER 

X(4) 

ID-NO 

ID-NO-ZONE 

9(3) 

ID-NO-AREA 

9(3) 

lO-OBGM 

FILLER 

x: 

ID-O-EOC 

99 

FILLER 

X(4) 

lO-NO 

lO-NO-ZONE 

9(3) 

lO-NO-AREA 

9(3) 

PRIORITY 

99999 

SERVICE 

9S 

DISTRIB-CODE 

X 

TRIP -TEAM 

99 

FUNCTION 

99 

SUPPORT-FUNC 

99 

TRIP-RESOURCES 

TRIP-RES 

9(6) 

Occurs  8 rimes-. 

TRIP-DEPARTURE 

9(3)V9 

TRIP-ARRIVAL 

9(3)V9 

TRIP-QTY 

9(6) 

MOB-CODE 

9 

FILLER 

X(66) 

1.  OPN-NO.  Operation  number  to  which  the  function  belongs. 

2.  II>-ORGN.  The  destination  organisation  number. 

3.  ID-MO.  The  tone  and  unit  area  Identification  nuBd>ers  of  destination. 

4.  lO-ORGM.  The  Identification  number  of  the  origin  organization  for 
%rhlch  the  trip  Is  being  performed. 
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Trip  File,  continued. 

J 

5.  lO-NO.  The  identification  number  of  the  origin  zone  and  unit  area 

where  the  trip  Is  starting.  | 

6.  PRIORITY.  Code  which  designates  the  priority  of  the  trip  to  be 
performed. 

7.  SERVICE.  Service  number  to  which  the  team  belongs.  (See  In  this 

appendix.  Section  H,  Organization  File,  part  3.)  i 

8.  DISTRIB-CODE.  The  network  code  (e.g.,  may  indicate  transportation, 
communication,  sewage,  or  power  lines,  etc.). 

9.  TRIP-TEAM.  The  Identification  number  of  the  team  performing  the  trip.  j 

10.  FUNCTION.  The  Identification  number  of  the  function  being  performed 
by  the  team. 

11.  SUPPORT- FUNC.  Undefined. 

12.  TRIP- RESOURCES.  The  resources  being  moved  (up  to  8,  l.e. , teams, 
spaces,  capacity  units,  equipment  sets,  rations,  water,  fuel,  and 
supply  units) . 

13.  TRIP-DEPARTURE.  The  departure  time  of  the  team. 
lA.  TRIP-ARRIVAL.  The  arrival  time  of  the  team. 

15.  TRIP-QTY.  The  number  of  teams  taking  the  trip. 

16.  MOB-CODE.  The  code  which  designates  whether  a vehicle  is  needed 

by  Che  team  In  performing  Its  assigned  function.  ij 

a.  1 Indicates  yes. 

b . 0 Indicates  no . f j 

il 

II 

li 


The  fornaC  for  Che  history  file  is  shorn  in  Table  J-I,  HISTORY-RECORD. 


I*  Table  J-I 

HISTORY-RECORD 

[ 

COBOL  COBOL 

i Variable  Format  Remarks 


;r 


1 

ii 
I 

[i 

r. 

n 


PRINT-DATA 

PRINT-CODE 

X(132) 

9 

Indicates  Che  type 
of  record  below 

1 - Operatiojs 

2 - Assignment 

3 - Trip 

1 

Operation  Printout 

(see  Operation  File 
for  explanation 

FILLER 

XXX. 

of  fields) 

PRINT-OPS-ORGN 

X(9). 

PRINT-AREA-ID-IO 

X(6). 

PRINT-LINK-CODE 

X. 

FILLER 

XX. 

PRINT-CURRENT-AREA 

X(7). 

PRINT-LAND-USE 

ZZ9. 

FILLER 

X. 

PRINT-TYPE-10 

X(ll). 

PR INT-START-T IME- 10 

ZZZ9. 

PRINT-PROBLEM-CODE 

ZZZ9. 

FILLER 

XXX. 

PRINT-OPS-SET 

• 

occurs  12  times 

PRINT-0 P-FUNC 

99. 

FILLER 

X. 

PRINT-CUR-ASGN 

Z99. 

FILLER 

X. 

PRINT-0 P8-1 

ZZZ9.9. 

PRINT-OPS-2 

ZZZ9.9. 

PRINT-OPS-3 

ZZZ9.9. 

PRINT-OPS-4 

ZZZ9.9. 

PRINT-OPS-QTY 

Z(7)9. 

PRINT-END-TIME 

Z(4)9.9. 
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Hiatory  File,  continued. 


COBOL 

COBOL 

Variable 

Format 

Remarks 

Aaaisnnent  Print-Out 

(see  Assignment  File 

PRINT-ASGN-ORGN 

X(9). 

for  explanation 

PRINT-ASGN-ORIGIN 

X(7). 

of  fields) 

PRINT-ASGN-AREA 

X(7). 

PRINT-ASGN-LAND-USE 

Z9. 

FILLER 

XX. 

PRIHT-ASGN-TYPE 

X(ll). 

PRINT-ASGN-PERIOD 

Z99. 

PRINT-ASGN-NO 

Z99. 

PRINT-ASGN-SEQ 

Z99. 

FILLER 

XX. 

PRINT-ASGN-FUNC 

X(13). 

PRINT-ASGN-TEAM 

X(  14). 

PRINT-RESOURCE-SET2 

i 

Occurs  8 times 

FILLER 

1 X. 

PRINT-RESOURCES-USED 

1 9(6). 

PRINT-KO-ASGN 

ZZZ9. 

PRIWT-XHRS-PREP 

Z(5)9.9. 

PRINT-XHRS-PROD 

Z(5)9.9. 

FILLER 

X. 

PRINT-BAL-PREP 

Z(5)9.9. 

PRINT-BAL-PROD 

Z(5)9.9. 

FILLER 

X. 

PRINT-BENEF IT-TYPE 

X(8). 

PRINT-ACTUAL-BENEFITS 

Z(6)9. 

PRINT-BAL-BENEFITS 

Z(6)9. 

Trip  Print-Out 

(see  Trip  File  for 

PRINT-LV 

ZZZ.9. 

for  explanation 

PRINT-AR 

ZZZZ.9. 

of  fields) 

FILLER 

X. 

PRINT-TYPE 

X. 

PRINT-ORIGIN 

Z(4). 

PRINT-O-LOC 

Z(3). 

PRIHT-DESTI 

Z(4). 

PRINT-D-LUC 

Z(3). 

FILLER 

X. 

PRINT-OPN 

X(13). 

FILLER 

X. 

PRINT-TEAM 

X(13). 

PRINT-NUM 

ZZZ9. 

PRINT-PRIORITY 

2(6). 

PRINT-PEOPLE 

Z(7). 

PRINT-FOOD 

Z(7). 

PRINT-DRINK 

Z(7). 

PRINT-WATER 

Z(7). 

PRINT-FUEL 

2(7). 

i 

PRINT-MED-PKGS 

2(7). 

PRINT-GAS 

2(7). 

PRINT-POWER 

2(7). 

PRINT-PARTS 

2(7). 

PRINT-PCT 

2(4). 
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K.  Performance  File 

The  format  for  the  performance  file  is  shown  in  Table  K-I,  PERFORMANCE- 
RECORD. 

Table  K-I 

PERFORMANCE-RECORD 


I 

I 

I 


COBOL 

Variable 

COBOL 

FORMAT 

Remarks 

TEAM-ZONE 

99 

TEAM-EOC 

99 

TEAM-AREA 

999 

TEAM-NO. 

99 

NO-OF-TEAMS 

9(6) 

occurs  3 times 

TEAM-HOURS 

9(8) 

TEAM-HOUR-GAIN 

9(8) 

TEAM-HOUR-LOSS 

9(8) 

TEAM-HOUR-DEMAND 

9(8) 

TEAM-HOUR-STATE 

9(8) 

occurs  9 times 

FILLER 

X(4) 

RECORD-PERIOD 

99 

RECORD-TYPE* 

X 

0 or  1 

*Note  - When  RECORD-TYPE  is  "1"  the  record  is  redefined  as  a Benefit- 


Record  (see  BENEFIT-FILE). 


K ■■ 


1 

I 


I 


1.  TEAM-ZONE.  Zone  location. 

2.  TEAM-EOC.  EOC  location. 

3.  TEAM-AREA.  Area  location. 

4.  TEAM-NO.  Identification  of  team  by  type. 

5.  NO-OP-TEAMS.  Total  number  of  teams  in  unit  area  of  specified  type. 

6.  TEAM-HOURS.  Total  potential  team-hours. 

7.  TEAM-HOURS-GAIN.  Team-hours  gained  during  period. 

8.  TEAM-HOURS-LOSS.  Team-hours  lost  during  period. 

9.  TEAM-HOURS-DEMAND.  Team-hours  needed  to  solve  problems. 

10.  7EAM-H0URS-STATE.  Amount  of  hours  in  each  of  9 possible  states. 

11.  RECORD-PERIOD.  Time  period. 

12.  RECORD-TYPE.  Either  team  readiness  or  benefit  data  as  indicated 

above. 
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Plot  File 


The  format  for  the  plot  file  is  shown  in  Table  L-I,  PLOT-DATA  FORMAT. 


Table  L-I 
PLOT-DATA  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Remarks 

PLOT-ZONE 

99 

PLOT-EOC 

99 

PLOT-AREA 

999 

PLOT-PERIOD 

99 

PLOT-TIME 

999V9 

PLOT-POP 

9(6) 

PLOT-COST 

9(8) 

PLOT-RWB-PRICE 

999V99 

PLOT-RDY-PRICE 

999V99 

PLOT-NORM 

9V999 

PLOT-PROB 

9V999 

PLOT-LOST 

9V999 

PLOT-RWB 

9V999 

PLOT-RDY 

9V999 

PLOT-RWB- S 

9V999 

PLOT-RWB-L 

9V999 

PLOT-RWB-J 

9V999 

PLOT-RWB-H 

9V999 

PLOT-RDY-S 

9V999 

PLOT-RDY-L 

9V999 

PLOT-RDY-J 

9V999 

PLOT-RDY-H 

■■■  1 

9V999 

1. 

PLOT-ZONE. 

Zone  location. 

2. 

PLOT-EOC. 

EOC  location. 

3. 

PLOT-AREA. 

Area  location. 

4. 

PLOT-PERIOD.  Interval  for  a given  pass. 

5. 

PLOT-TIME. 

Time  in  hours  at  the  end  of  the  PLOT-PERIOD 

6. 

PLOT-POP. 

Surviving  population  plus  the  dead. 

7. 

PLOT-COST. 

Cost  in  team  hours. 

8. 

PLOT-RWB-PRICE.  Team  hours  for  a unit  of  well-being. 

9. 

PLOT-RDY-PRICE.  Team  hours  of  readiness. 

10. 

PLOT-NORM. 

Normal  population. 

11. 

PLOT-PROB. 

Problem  population. 
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Plot  File,  continued. 


12. 


13. 


14. 


15. 


16. 


17. 


18. 


19. 


20. 


21. 


22. 


PLOT-LOST.  The  number  of  people  dead. 

PLOT-RWB.  The  current  average  relative-well-being  of  the  surviving 
population. 


PLOT-RDY.  A value  expressing  the  degree  (o  which  the  resources  are 
available  to  solve  the  problems  of  the  surviving  population. 
PLOT-RWB-S.  The  surviving  population  for  relative-well-being. 
PLOT-RWB-L.  Fraction  denoting  labor  potential  of  the  surviving 


population. 

PLOT-RWB- J.  Fraction  of  the  surviving  population  with  jobs. 
PLOT-RWB-H.  Fraction  of  the  surviving  population  who  have  housing 
facilities. 


PLOT-RDY-S.  The  surviving  population  for  readiness. 

PLOT-RDY-L.  A value  expressing  the  degree  to  which  the  labor  poten- 
tial Is  available  to  solve  the  problems  of  the  surviving  population. 
PLOT-RDY-J.  The  number  of  jobs  availably  to  solve  the  problem  pop- 
ulation. 


PLOT-ROY-H.  The  number  of  housing  facilities  available  to  solve  the 
problem  population. 
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M.  Bcmflts  File 

i 

Th«  fonuc  for  the  benefits  file  is  shown  in  Teble  M-I,  BENEFIT-DATA  J 

FORMAT.  I 

Teble  M-I 


BENEFIT-DATA  FORMAT 


COBOL 

Variable 

COBOL 

Format 

Reswrks 

BENEFlT-RECl 

BENEFIT-ORGN 

BENEFIT-ZONE 

99 

BENEFIT-EOC 

99 

BENEFIT-AREA 

999 

BENEFIT-POP 

9(6) 

Occurs  10  times. 

THRS-AVAIL 

9(8) 

Occurs  5 times. 

PREVIOUS-POP 

9(6) 

BENEFIT-REC2 

THRS-DEV 

9(8) 

Occurs  5 times. 

THRS-PRD 

9(8) 

Occurs  4 times. 

THRS-PHO-DEV 

9(8) 

Occurs  4 times. 

BENEFIT-REC3 

THRS-DEMAND 

9(8) 

Occurs  3 times. 

THRS-DEMAND-DEV 

9(8) 

Occurs  5 times. 

THRS-DEMAND-PRO 

9(8) 

Occurs  4 times. 

BENEFIT-REC4 

THRS-DEMAND-PRO-DEV 

9(8) 

Occurs  4 times. 

TEAMS-DEV 

9(6) 

Occurs  S times. 

FAC-AVAIL 

9(6) 

Occurs  3 times. 

FAC-AT-RISK 

9(6) 

Occurs  3 times. 

TEAMS-PRO-DEV 

9(6) 

Occurs  3 times. 

1.  BENEFIT-RECl 

e.  BENEFIT-ORGN . Location  of  the  benefits. 

(1)  BENEFIT-ZONE.  Zone. 

(2)  BENEFIT-EOC.  EOC. 

(3)  BENEFIT-AREA.  Area. 

b.  BENEFIT-POP.  The  nuaber  of  people  assigned  to  the  following 
categories : 

(1)  1 indicates  housed. 

(2)  2 indicates  employed. 

(3)  3 indicates  healthy. 

(4)  4 indicates  survivors  with  a problem. 


1 


N 

i! 

y 

ri 
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Benefits  File,  continued. 

(5)  S Indicates  control. 

(6)  6 Indicates  dead. 

(7)  7 Indicates  problem. 

(8)  8 Indicates  total. 

c.  THRS-AVAIL.  The  number  of  team  hours  available  for  codes 
1 - 5 In  BENEFIT-POP  (b.  above). 

d.  PREVIOUS-POP.  The  previous  population. 

2.  BENEFIT-REC2 

a.  THRS-DEV.  The  team  hours  assigned  to  reclaim  Inoperative  teams 
for  use  In  serving  the  problem  population. 

b.  THRS-PRO.  The  number  of  team  hours  available  to  protect  un- 
damaged facilities  or  restore  damaged  facilities  during  the 
next  period. 

c.  THRS-PRO-DEV.  The  number  of  team  hours  assigned  to  reclaim 
Inoperative  teams  during  the  next  period. 

3.  BENEFIT-REC3 

a.  THRS-DEMAND.  The  number  of  team  hours  In  demand  by  the  problem 
population. 

b.  THRS-DEMAND- DEV.  The  number  of  team  hours  needed  to  reclaim 
Inoperative  teams  for  use  In  serving  the  problem  population. 

c.  THRS-DEMAND-PRO.  The  number  of  team  hours  needed  to  protect 
undamaged  facilities  or  restore  damaged  facilities  during  the 
next  period. 

4.  BENEFIT-REC4 

a.  THRS-DEMAND-PRO-DEV.  The  number  of  team  hours  needed  to  reclaim 
Inoperative  teams  during  the  next  period. 

b.  TEAMS-DEV.  The  number  of  teams  that  arc  inoperative  but  who  can 
serve  the  problem  population  If  reactivated. 

c.  FAC-AVAIL.  The  undamaged  facilities  available  for  BENEFIT-POP 
codes  1-3  (see  l.b.  above). 

d.  FAC-AT-RISK.  The  damaged  facilities  which  can  be  restored  to 
serve  the  problem  population. 

a.  TEAMS-PRO-DEV . The  number  of  teams  that  arc  Inoperative 

but  can  be  uaed  to  restore  facilities  to  be  used  in  serving 
the  problem  population. 
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Link«  File 

The  format  for  the  links  file  is  shown  in  Table  N-I,  LINKS  DATA  FORMAT. 

^ Table  N-I 
LINKS  DATA  FORMAT  ^ 


COBOL 

Variable 


COBOL 

Format 


Remarks 


ZONE 

EOC 

GROUP 

SECTOR 

NETWORK-NO 

FWD-NODE 

LVL  FOR 

BWD-NODE 

LVL  BAC 

LINK-NO 

LINK-NAME 

UA-NO-L 

NTWK-NO-L 

UA-NO-L 

NTWK-NO-R 

LENGTH 

WIDTH 

TYPE 


9999 

x(ll) 

999 

999 

999 

999 

9V9 

9 

XX 


ZONE  i.d.  number 
EOC  i.d.  number 
Group  i.d.  number 
Sector  i.d.  number 
Unit  Area  i.d.  number 
Forward  node  i.d.  number 
Level  of  forward  node 
Backward  node  i.d.  number 
Level  of  backward  node 
Link  i.d.  number 
Link  name 

Unit  area,  left  of  link 
Network,  left  of  link 
Unit  area,  right  of  link 
Network,  right  of  link 
Length  of  link  in  miles 
Width  of  link 
Use- type  of  link 
Direction  of  link 
Room  for  further  expan- 
sion; variables  for 
queuing  model 


Notes: 

^ This  file  should  be  sorted  by  ZONE,  EOC,  CROUP,  SECTOR,  and 
NETWORK-NO  in  ascending  ordar. 

2 A record  with  NETWORK-NO  ■ 999  separates  networks. 


II 
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Links  File,  continued 


1.  ZONE.  Zone  locetion. 

2.  EOC.  EOC  location. 

3.  GROUP.  Group  location. 

4.  SECTOR.  Sector  location. 

<7 

5.  NETWORK-NO.  A unique  heirarchical  number  reflecting  the  network 

position  in  the  overall  network. 

6.  FVD-NODE.  The  definition  is  illustrated  in  the  following  diagram 

for  two  nodes  A and  B and  illustrates  the  definition 
of  forward  and  backward  nodes.  The  indicated  angle, a, 
about  node  A is  less  than  180  degrees,  therefore,  A is 
the  backward  node  and  B is  the  forward  node. 


7.  LEVFOR.  Level  codes  are  used  to  define  higher  level  networks. 
Code 

1 Interior  to  unit  area  or  not  shared  with  other  areas 

2 Shared  between  unit  areas 

3 Shared  between  sectors 

4 Shared  between  groups 

5 Shared  between  FOC's 

6 On  the  boundary  of  sones 

8.  BWD-NOOE.  (see  6.  above) 

9.  LEV  BAC.  (see  7.  above) 


Links  Pile,  continued 


17. 

18. 


NTVK-NO-L.  Network  number  pertaining  to  12  above. 

UA-NO-R.  Unit  area  number  on  right  aide  of  link. 

NTWK-*NO-R.  Network  number  pertaining  to  14  above. 

Length.  Length  of  link  in  miles. 

Width.  Width  of  link  in  terms  of  number  of  lanes. 

Type.  Use-type  of  link  (currently  restricted  to  highways  but  type 
codes  *rill  be  used  to  distinguish  between  highways, 
railways , seaways  , etc.) 
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0.  Travl  R«fer«nce  File 


The  format  for  the  file  is  shown  in  Table  O-I,  TVL-REF  FORMAT. 


I 


1 


I 


I 


i 


I 

\ 

i 

I 


I 

(1 


Table  0-1 
TVL-REF  FORMAT 


COBOL 

Variable 

COBOL 

Format 

— 

Remarks 

TVL-ORGN 

R-ZONE 

99 

R-EOC 

99 

R-GRP 

99 

R-SEC 

99 

LEVEL-CODE 

9 

TVL-TIME 

9(2)V99 

R-AREA 

AREA-Z 

999 

AREA-R 

999 

TVL-CODE 

X 



1.  TVL-ORGN.  Reference  identification  number. 

a.  R-ZONE.  Reference  zone. 

b.  R-EOC.  Reference  EOC. 

c.  R-GRF.  Reference  group. 

d.  R-SEC.  Reference  sector. 

2.  LEVEL-CODE.  Gives  the  level  of  location  of  data. 

a.  1 designates  an  EOC  area. 

b.  2 designates  a GROUP  area. 

c.  3 designatea  a SECTOR  area. 

d.  4 designates  the  nearest  unit  area  in  adjacent  EOC's. 

3.  TVL-TIME.  Average  travel  time  within  an  area  defined  by  the  LEVEL- 
CODE,  if  TVL-CODE  - 1.  If  TVL-CODE  - 3,  it’s  the  time  between  two 
specific  points  such  as  the  origin  and  destination. 
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Travel  Rafe ranee  File 


continued 


4.  R-AREA 

a.  AREA-Z.  Zone  of  Che  area. 

b.  AREA-R.  Indicates  Che  area  within  the  EOC  (the  origin  area  If 
TVL-CODE  > 2;  If  TVL-CODE  • 3,  Chen  a destination  area.  AREA~R 
la  blank  if  TVL-CODE  - 1 or  4). 

5.  TVL-CODE. 

a.  1 Is  the  Indicator  used  to  generate  Che  nearest  EOC  table. 

b.  2,  3,  and  4 are  used  to  generate  the  travel  table 
only  to  Che  EOC  at  that  time  of  execution) . 

c.  4 Indicates  the  EOC  area. 
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